How can I mirror Stash repositories to non-Stash servers for local users

[Mark Montminy]

We're planning to setup a centralized Stash instance to bring some order to the number of Gerrit/Gitosis/Gitlab/server-of-the-month instances popping up around the company.

Buy-in to this is mixed, because the engineers feel that working with a remote instance will be too slow. Clones of large repos over the WAN, especially to other countries, will take too long.

What I'm trying to figure out, is how to safely and reliably mirror the repos that Stash is hosting, out to more local in-country non-stash servers, that users can clone/pull from. I expect everyone would have to push back to the Stash instance, and that's acceptable. We have similar models with SVN today, on-site mirrors, users push back to the primary master.

Has anyone tacked this, and if so, how? 

[Jobin Kuruvilla [Adaptavist]]

We have implemented this solution (Geo clustering) with mirrors in various countries. Clone will happen from the mirror whereas push will go to primary Stash. Reach out to sales at go2group dot com if interested to know more about the solution.

[Daniel Wester]

It sounds like you've got people that aren't used to working with Git and are probably combining the git commit operation with the git push operation. It might be as simple as an educational exercise to teach users to teach about how to break those 2 actions apart.

[Mark Montminy]

No, our GIT users are using it properly. A clone is a clone, and if you need to pull several gigs of data over a WAN connection, GIT or not, it takes time. Time is money and productivity loss. The intent is to have in-country repos that are kept up to date with the main Stash hosted repos. This will allow engineers to clone more efficiently, and push back to the main Stash instance.

[Mike Friedrich]

You would need to specify how often you plan to clone, push and fetch and how much data you expect for each of these operations, and how much of these do you expect to run parallel.

Clone operations are said to be the critical part in Stash, but if you have huge fetch and push operations (in GB range) they effect the performance too.

Based on these information you need to adjust the hardware resources of the Stash server (basically memory and number of cores).

We use Stash remotly over WAN and LAN.

To deal with clones (some of hour repos are several GB large), we prepare zip's of full clones with any needed hooks in regular intervals (every some months). Developers can copy and extract these and fetch the diffs sinc the zip was created and can start working. Typically this is much faster than cloning via Stash - espessially if using WAN, and it puts no load on the Stash server. At some point i will use Bamboo to create these zips and keep them updated, but have not implemented this yet.

You can also use git standard clone feature to mirror repos. To keep them up-to-date you can fetch from Stash (cron or scheduled job) and disallow any pushes (otherwise this will get very complicated). Also by default if people clone from a mirror the origin is not the Stash server. They always need to update their remotes (and maybe other settings/hooks) afterwards and thats error prone. I see not so much benefit (for us) in this compared to the zip-method, because clones are not done so often.

Edit:
Just for information, fetching and pushing the daily work has never been an issue for us over the WAN. It is a bit slower, but no problem at all as it transmit diffs only.