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 <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.

--
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