Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-3751

Allow historical aliasing of projects and repositories

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Stash currently allows renaming repositories and projects. However if this is done, all users who have cloned the repository or bookmarked the web URL will have update them accordingly and get no prompt or information as to where it exists now.

      Stash should keep a record of original project keys / repository slugs when operations are performed which can changed them. It could then provide a redirect in the browser amd output the git remote set-url command to use when attempting to clone/fetch/push to with an old url.

            [BSERV-3751] Allow historical aliasing of projects and repositories

            mark-1003 added a comment -

            Is there any documentation about this feature available?

            • How does it work?
            • In which cases is there a redirect to the old URL? Everytime?
            • How long does this redirect exist?
            • Is there a page where all active redirects can be seen?
            • ...

            mark-1003 added a comment - Is there any documentation about this feature available? How does it work? In which cases is there a redirect to the old URL? Everytime? How long does this redirect exist? Is there a page where all active redirects can be seen? ...

            Hi, so i tested this with Bitbucket Server 6.4.3 and it seems to work. Nevertheless there is a problem left.

            Assume that you moved a repo A from Project X to Y.

            It turns out, that you can create an new repository B in X with the name of project A. So the clone URL will have the exact same name as repo A had before moving it to Y and where it is still pointing to. 

            The newly created repo B cannot be accessed since the URL is pointing to A.

            In my point of view, Bitbucket should not allow to create a repo in X with the name of A OR needs to alter the clone url.

            Oliver Zabel added a comment - Hi, so i tested this with Bitbucket Server 6.4.3 and it seems to work. Nevertheless there is a problem left. Assume that you moved a repo A from Project X to Y. It turns out, that you can create an new repository B in X with the name of project A. So the clone URL will have the exact same name as repo A had before moving it to Y and where it is still pointing to.  The newly created repo B cannot be accessed since the URL is pointing to A. In my point of view, Bitbucket should not allow to create a repo in X with the name of A OR needs to alter the clone url.

            I see this was resolved a couple years ago in version 5.0, but for the life of me I cannot find out how it was resolved, i.e. how do I move a repository to a different project while keeping the old URL? All of my attempts at Googling have only led me to tickets such as these, and I haven't seen anything jump out of me from the official documentation. FWIW, it would be helpful for all resolved "feature suggestion" tickets if they linked to the relevant documentation. 

            David Deutsch added a comment - I see this was resolved a couple years ago in version 5.0, but for the life of me I cannot find out  how it was resolved, i.e. how do I move a repository to a different project while keeping the old URL? All of my attempts at Googling have only led me to tickets such as these, and I haven't seen anything jump out of me from the official documentation. FWIW, it would be helpful for all resolved "feature suggestion" tickets if they linked to the relevant documentation. 

            @Andrei I'm not familiar with how Github's solution works so I can't speak to that.
            What I'm looking for is a means to allow me to move a repository from one project to another but allow old references to the repository URL to still be valid and continue to work. I suspect others may want to have old project URLs also be valid and the solution proposed by myself and Ken would not address that. I wouldn't want to replace the repository name with a numeric identifier as that would make matching URLs to repos nearly impossible. I guess the same would hold for projects as well.

            I have considered something like you suggest, redirecting the old URL to a new URL but haven't had the time to try a solution out.

            Steven Whitman added a comment - @Andrei I'm not familiar with how Github's solution works so I can't speak to that. What I'm looking for is a means to allow me to move a repository from one project to another but allow old references to the repository URL to still be valid and continue to work. I suspect others may want to have old project URLs also be valid and the solution proposed by myself and Ken would not address that. I wouldn't want to replace the repository name with a numeric identifier as that would make matching URLs to repos nearly impossible. I guess the same would hold for projects as well. I have considered something like you suggest, redirecting the old URL to a new URL but haven't had the time to try a solution out.

            @Ken @Steven: from where I stand, what you propose is a different thing altogether than what this ticket is about. You basically want to elude the aliasing altogether by creating "true identifiers" from day one, for git clone. So if the repo id is 1 (Stash already assigns incremental repo ids), you're advocating for presenting the clone command as "git clone git@stash.tail-f.com:1.git" or smth like that. I would create an entirely new ticket for that.

            Sticking strictly to this ticket's take i.e. á la Github solution (redirection), as a poor-man's workaround, did anyone try symlinking the repos on the file system? If that works fine, you also need some javascript that checks "am I on repo OLD_PROJ/repo/old_repo, which was moved to NEW_PROJ/repo/new_repo? then compile and redirect to the URL" — an extension could inject this javascript.

            Andrei Neculau added a comment - @Ken @Steven: from where I stand, what you propose is a different thing altogether than what this ticket is about. You basically want to elude the aliasing altogether by creating "true identifiers" from day one, for git clone. So if the repo id is 1 (Stash already assigns incremental repo ids), you're advocating for presenting the clone command as "git clone git@stash.tail-f.com:1.git" or smth like that. I would create an entirely new ticket for that. Sticking strictly to this ticket's take i.e. á la Github solution (redirection), as a poor-man's workaround , did anyone try symlinking the repos on the file system? If that works fine, you also need some javascript that checks "am I on repo OLD_PROJ/repo/old_repo, which was moved to NEW_PROJ/repo/new_repo? then compile and redirect to the URL" — an extension could inject this javascript.

            @Ken: Yes I agree with the requirement that URLs should be unique (as I stated as well) so that they never change even when moving a repo to another project. I was just pointing out that your original example wouldn't work in some situations.

            Steven Whitman added a comment - @Ken: Yes I agree with the requirement that URLs should be unique (as I stated as well) so that they never change even when moving a repo to another project. I was just pointing out that your original example wouldn't work in some situations.

            @Steven: yeah, it's necessary to have unique URLs, but sticking the project ID in there to improve the odds certainly isn't the only way to achieve that. Another way would be to stick a random 4-digit number at the beginning or end. Another way would be to default to the normalized repository name, and if there's a conflict, tell the user "this repository ID exists, please choose another ID", without needing to change the web-visible name.

            Ken Williams added a comment - @Steven: yeah, it's necessary to have unique URLs, but sticking the project ID in there to improve the odds certainly isn't the only way to achieve that. Another way would be to stick a random 4-digit number at the beginning or end. Another way would be to default to the normalized repository name, and if there's a conflict, tell the user "this repository ID exists, please choose another ID", without needing to change the web-visible name.

            I think it's necessary to have the project name or some other unique name in the URL. For a large organization, trying to keep all repo names unique might be an issue. For organizations that use forks, it may also be desirable to keep the repo name the same. One solution would be to create a unique identifier when the repo is created on Stash but doesn't change when moved. This URL needs to work for GIT operations (clone, fetch, etc) and for references to Stash pages for browsing.

            Steven Whitman added a comment - I think it's necessary to have the project name or some other unique name in the URL. For a large organization, trying to keep all repo names unique might be an issue. For organizations that use forks, it may also be desirable to keep the repo name the same. One solution would be to create a unique identifier when the repo is created on Stash but doesn't change when moved. This URL needs to work for GIT operations (clone, fetch, etc) and for references to Stash pages for browsing.

            Yes, this is very much a desired feature for us too. Our project structure in Stash has grown extremely messy, but rearranging things would be very intrusive for our developers and automated processes (including Bamboo builds). Lots of stuff would break, so the pain of keeping the bad organizational structure is probably less than the pain of fixing it.

            There's really no reason to put the Project code for a repository in its URL - for us, the ideal option would be to make repository names (the "FOO" in "ssh://git@stash.example.local:7999/PROJ/FOO.git") globally unique, remove the project name (the "PROJ" part), and then when repos move projects, they're not broken.

            Ken Williams added a comment - Yes, this is very much a desired feature for us too. Our project structure in Stash has grown extremely messy, but rearranging things would be very intrusive for our developers and automated processes (including Bamboo builds). Lots of stuff would break, so the pain of keeping the bad organizational structure is probably less than the pain of fixing it. There's really no reason to put the Project code for a repository in its URL - for us, the ideal option would be to make repository names (the "FOO" in "ssh://git@stash.example.local:7999/PROJ/FOO.git") globally unique, remove the project name (the "PROJ" part), and then when repos move projects, they're not broken.

            Johannes Kilian added a comment - - edited

            As we have several external configuration files, pointing to a git repo hosted at STASH each movement of a repo by a user results in the need of updating those configuration files ...

            So this IS still a much desired feature on our side ... (at least the wish for PERSISTENT Urls ...)

            Johannes Kilian added a comment - - edited As we have several external configuration files, pointing to a git repo hosted at STASH each movement of a repo by a user results in the need of updating those configuration files ... So this IS still a much desired feature on our side ... (at least the wish for PERSISTENT Urls ...)

              mheemskerk Michael Heemskerk (Inactive)
              jhinch jhinch (Atlassian)
              Votes:
              44 Vote for this issue
              Watchers:
              31 Start watching this issue

                Created:
                Updated:
                Resolved: