Konstantin - thanks for your reply - fantastic details response! :-)

I'll go through in more detail, but wanted to get you a fast basic response 

your last sentance says it all really - ie a single repository with VPN 
access. However - our main problem is that a large number of changes in the 
UK will take a long time to get when the US office come on-line (we have 
lots of HTML etc). With SVN we can configure it to synch a copy to a 
read-only repo in the US. This can also be configured such that any commits 
are done to this read-only repo, but are * automatically routed to the main 
repo in the UK* ...this makes for an easy and fast (for "check-out" anyway) 
solution for the US team. Git does not seem to help here...


On Thursday, December 19, 2013 1:35:26 PM UTC, Konstantin Khomoutov wrote:
> On Thu, 19 Dec 2013 04:42:13 -0800 (PST) 
> Oliver Harvey <o...@tigertechsoftware.com <javascript:>> wrote: 
> >  ...our main requirement is for changes made in the UK available to 
> > be available the US for fast/easy check-out (check-in not so 
> > important). 
> > 
> > SVN can crack this either via WanDisco (commercial), or via some 
> > master-slave auto-sync thing- 
> > 
> > -Does Git help us with this at all? - perhaps it makes it *more 
> > difficult* by requiring a two-step push?? 
> Hmm, I don't quite get the problem.  As you mention pushes, supposedly 
> you imply you have a central repository to which your devs (or whoever 
> else) push changes from their private repos, right?  If yes, then 
> what's the problem of making this central "rendez-vous" repository 
> available to both UK and US offices?  Say, by means of a VPN tunnel, a 
> private Git hosting etc. 
> If this is impossible/undesirable for some reason, you can either set 
> up automated *mirroring* by hand or use a ready-made solution (such as 
> that provided by gitolite).  The way to implement mirroring depends on 
> whether you want "passive" (or "pull") style, when the US office 
> periodically checks to see if there's anything new in the UK central 
> repo) or "active" (or "push") style, when a post-update hook set in the 
> US shared repository queues a task to push the changes from that 
> repository to the one in the US office. 
> Pull-style mirroring is easy: 
> 1) Create an initial bare mirror clone: 
>    us_server$ cd /srv/git 
>    us_server$ git clone --bare --mirror ssh://git@uk-server/uk.git 
> 2) Set up a cron job that just `cd`-s to /srv/git/uk.git and 
>    runs `git fetch` there.  The refspec (the "what to fetch" 
>    specification) set up by the initial clone operation should make 
>    `git fetch` grab everything the remote has and update the 
>    local stuff with that. 
> Push-style mirroring is harder because you has to compensate for 
> possible case of rapid pushing where someone updates the repo so fast 
> several copies of the post-update script propagating the changes are 
> spawned because they are slow to complete.  So some sort of locking or 
> queuing should supposedly be implemented.  As to how to do such 
> mirror-push, you just do something like 
>   uk_server$ git push ssh://git@us-server '+refs/*:refs/*' 
> where the refspec +refs/*:refs/* tells Git to send all the refs 
> (branches and tags) existing locally to the refs with the matching 
> names on the remote side, creating them if necessary, and also 
> force-updating them if needed ("+"). 
> Of course, the remote repo must be bare and must accept forced updates 
> (this is the default). 
> Surely, you might opt to do more fine-grained synchronizing by pushing 
> or fetching only a set of selected branches.  This will just make your 
> refspecs more involved, and will possibly require you to also use the 
> --tags command-line option.  Read the git-fetch and git-push manual 
> pages carefully. 
> To recap, in my opinion, the best option is to just provide direct 
> network access to the single shared repository (or a set of them if 
> several projects are being collectively worked on) to both offices by 
> means of a VPN or by using shared Git hosting (making it by hand on a 
> cheap VPS/VDS is also an option). 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to