Hi Oliver,
You can set different repos for push and pull for US developers, so that
US pull from the read-only US mirror, but pushes to the UK repo. There
will be a short delay before the changes are visible in the US mirror if
you use the "pull" strategy as described by Konstantin.
git remote set-url --push origin ssh://uk-server/ourproduct.git
In .git/config:
[remote "origin"]
url = ssh://us-server/ourproduct.git
fetch = +refs/heads/*:refs/remotes/origin/*
pushurl = ssh://uk-server/ourproduct.git
The US mirror should be setup to pull periodically/continuously. This
alternative would be similar to the SVN setup you use.
We have the above setup when working with Gerrit, except that even the
UK office would use a read-only mirror. The mirrors help reduce load on
the central server, and clone/fetch times. Pushes are not allowed to the
mirrors.
BR
Gunnar
On 12/19/13 14:55, Oliver Harvey wrote:
Konstantin - thanks for your reply - fantastic details response! :-)
I'll go through in more detail, but wanted to get you a fast basic
response first.
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...
Oli.
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 <[email protected] <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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
