deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

(mirroring doc) explain how this is more than just 'backup'

Browse source
This commit is contained in:
Sitaram Chamarty 2011-08-14 07:03:58 +05:30
parent a3ffc9d8fd
commit e3b1fdfd69
1 changed files with 56 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

82
doc/mirroring.mkd
View file

@ -5,24 +5,17 @@ Mirroring a repo is simple in git; you just need code like this in a
#!/bin/bash #!/bin/bash
git push --mirror slave_user@mirror.host:/path/to/repo.git git push --mirror slave_user@mirror.host:/path/to/repo.git
# if running gitolite, the $GL_REPO variable could be useful:
# git push --mirror slave_user@mirror.host:/repo/base/path/$GL_REPO.git
The hard part is managing this across multiple mirror sites with multiple For a lot of people, though, mirroring is more than just 'backup', and their
repositories being mirrored. needs are complex enough that setup is hard.
**This document has been tested using a 3-server setup, all installed using
the "non-root" method (see doc/1-INSTALL.mkd). However, the process is
probably not going to be very forgiving of human error -- like anything that
is this deep in "system admin" territory, errors are likely to be costly. If
you're the kind who hits enter first and then thinks about what he typed,
you're in for some fun times ;-)**
**On the plus side, everything we do is done using git commands, so things are
never *really* lost until you do a `git gc`**.
---- ----
In this document: In this document:
* <a href="#_why">why</a>
* <a href="#_RULE_NUMBER_ONE_">RULE NUMBER ONE!</a> * <a href="#_RULE_NUMBER_ONE_">RULE NUMBER ONE!</a>
* <a href="#_what_will_will_not_work">what will/will not work</a> * <a href="#_what_will_will_not_work">what will/will not work</a>
* <a href="#_concepts_and_terminology">concepts and terminology</a> * <a href="#_concepts_and_terminology">concepts and terminology</a>
@ -41,6 +34,33 @@ In this document:
---- ----
<a name="_why"></a>
### why
This document is useful if:
* you have multiple repositories spread across multiple sites around the
country/world, and would like developers to access their local server
instead of hitting the WAN, at least for 'fetch' operations.
* you don't want all your repos mirrored to all the servers for various
reasons, technical or otherwise (epecially true when some of the mirrors
don't belong to you).
* you want some mirrors to be updated only at certain times of the day,
(with a simple command), instead of every time a push happens.
* you don't want *one* server being the master server for *all* repos;
instead you want to choose where a repo gets "mastered" based on where the
majority of that repo's users are.
* you might even, if your servers are all in your control, want the
convenience of them *pushing to a mirror*, and having the push redirect
transparently to the master server.
As you can see, this is a bit more than a backup solution ;-)
<a name="_RULE_NUMBER_ONE_"></a> <a name="_RULE_NUMBER_ONE_"></a>
### RULE NUMBER ONE! ### RULE NUMBER ONE!
@ -59,23 +79,33 @@ recovers.
### what will/will not work ### what will/will not work
This process will only mirror your git repositories, using `git push * This process will *only* mirror your git repositories, using `git push
--mirror`. It will not mirror log files, and repo-specific files like --mirror`. It will *not* mirror log files, and repo-specific files like
`gl-creater` and `gl-perms` files, or indeed anything that was manually `gl-creater` and `gl-perms` files, or indeed anything that was manually
created or added (for example, custom config entries added manually instead of created or added (for example, custom config entries added manually
via gitolite). instead of via gitolite).
None of these affect actual repo contents of course, but they could be None of these affect actual repo contents of course, but they could be
important, (especially the gl-creator, although if your wildcard pattern had important, (especially the gl-creator, although if your wildcard pattern
"CREATOR" in it you can recreate those files easily enough anyway). had "CREATOR" in it you can recreate those files easily enough anyway).
Mirroring has not been, and will not be, tested when gitolite is installed * This document has been tested using a 3-server setup, all installed using
using the deprecated 'from-client' method. Please use one of the other the *non-root* method (see doc/1-INSTALL.mkd). However, the process is
methods. probably not going to be very forgiving of human error -- like anything
that is this deep in "system admin" territory, errors are likely to be
costly. If you're the kind who hits enter first and then thinks about
what he typed, you're in for some fun times ;-)
Also, none of this has been tested with smart-http. I'm not even sure it'll On the plus side, everything we do is done using git commands, so things
work; http is very fiddly to get right. If you want mirroring, at least your are never *really* lost until you do a `git gc`.
server-to-server comms should be over ssh.
* Mirroring has *not* been, and will not be, tested with gitolite installed
using the deprecated 'from-client' method. Please use one of the other
methods.
* Also, this has *not* been tested with smart-http. I'm not even sure it'll
work; http is very fiddly to get right. If you want mirroring, at least
your server-to-server comms should be over ssh.
<a name="_concepts_and_terminology"></a> <a name="_concepts_and_terminology"></a>