I'm looking at Stash to replace our existing git server, which just uses gitweb.
One of the major challenges with such a project would be the fact that the paths to the repositories would change. So, for example, a path at the moment might be something like:
whereas on Stash, it would be:
Similarly for git:// and http://URLs.
So my question is this: is there any way that I can set up the server so that if a user tries to pull from an "old" path, it works but gets the code from the "new" path? I'm not so worried about pushes but pulls would be the key thing to address here.
I would suggest switching your existing server to read-only and mirror the repositories from Stash to the old server. This would allow people to continue to clone/fetch from the original location but as soon as they attempt to push to it they will need to change their remote to Stash.
This was exactly how we did our 400+ repo migration. It worked fine and the users immidiately updated their remotes at their first push.
This approach also gave us some time to re-direct all "systems" using our git repos. We didn't had to move all build-servers, sonar-servers, selenium etc at the time of the migration since they still got the repos from the mirror (10 mintes later though) Now we have migrated most of these as well under more controlled forms.
edit: we used the Git Repository Mirror Manager plugin
Hi - thanks to you both for sharing this approach.
To make sure I understand what is being suggested, for each of the repos, I need to:
1. Clone the repo from the old server to the new server
2. Use Git Repository Mirror Manager to mirro the repo back to the old server. According to https://bitbucket.org/kostmo/stash-plugins/src/13f28cd3886b901d1c787d0f5203de602bc4edd3/mirror-manager/?at=master, it looks like I also have to do some work on the old server to set up the mirroring.
How do I ensure that when someone pulls the repo from the old server, subsequent pulls and pushes will be to the new server, or does that happen automatically because the new server is mirroring to the old server and therefore overriding the repo config including the repo paths?
I'm struggling to get Git Repository Mirror Manager working but I'll try contacting the developer to see if he can help, even though it says unsupported.
I've switched from Git Repository Mirror Manager to Repository Mirror Plugin for Stash (https://marketplace.atlassian.com/plugins/com.englishtown.stash-hook-mirror/versions#b28). It has better documentation and supports SSH keys, which is where I was getting stuck with GRMM.
I'm still struggling, though, to figure out how the repo config gets updated. I've tried following the instructions in https://answers.atlassian.com/questions/54235/importing-an-existing-repository-into-stashand https://confluence.atlassian.com/display/STASH/Importing+code+from+an+existing+projectbut that doesn't sort out the URLs when I do a pull from the old server.
This is how we have set it up:
This is the procedure I used and it worked in our environment. It assume the approach is workable in any environment with some tweaks added.
Let me know what you think!
Thanks very much for this, Svante. Absolutely what I was looking for.
The slight downside, and I guess I was hoping too much for it to be automatic, is that users will need to update their remotes :-(. It means that there isn't really any way to essentially force a migration away from the old server to the new one since we are entirely in the hands of the users to update their paths. If they don't do it, they'll continue to pull from the old server.
I guess the only thing that would force them to update their paths would be the fact that they couldn't commit to the old server, but an automatic process would have been nice to avoid that pain, but I think that is just a limitation of how the git tools work.
I understand you! But I don't see this as an issue, actually. If a user is continuing to pull from the git-repo that would be ok (with a slight lag of course) and as you point out when they try to push they will receive a permission error which they themselves can correct very easy.
This is a consequence of a distributed version control system. It is hard to centrally control the distributed clones. The pros outweigh the cons, though :-)
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot