On Thu, 19 Dec 2013 04:42:13 -0800 (PST)
Oliver Harvey <o...@tigertechsoftware.com> 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