[ANNOUNCE] Gitolite v2.1 and mirroring features

Sitaram Chamarty sitaramc at gmail.com
Fri Sep 30 07:44:33 BST 2011


Hello all,

I've kinda stopped sending "announce" emails for all the little
features and enhancements that happen to gitolite, but this one seemed
big enough and important enough to send one out to this list.

Gitolite v2.1 now does mirroring much more flexibly and powerfully
than the old, rather naive, setup.

Most of the impetus for these changes came from a rather large product
development group within TCS, the company I work for -- many cities,
offices, servers, repos, and developers.

Here are the highlights:

(1) the "NUMA" thing: Different repos can now be mastered on different
servers, depending on which city/office has the most developers for
*that* project.

This was the single biggest motivator for the new mirroring code; the
rest of the cool stuff just happened along.

(2) almost as good as "active-active" mirroring: If the "master"
server trusts the authentication performed by the "slave" server, you
can have the slave internally redirect a "git push" to the correct
master.

With this, developers don't have to remember which repo is mastered
where, use different 'pushurl's, etc.  They just do *everything* with
their local mirror and let the system deal with it.  (You can even
change which server is "master" and people don't even need to know it
has changed!)

(3) partial mirrors and local repos: A server doesn't have to carry
*all* the repos in the system -- it can choose to carry only some.

In our case it was often because there were no developers for that
project in that office, but there could be other reasons.  Server
load/resource constraints, legal/jurisdictional issues, server in a
non-free country and repo has crypto code ;-) etc.

Similarly, a server can have repos that it wants to keep purely local
-- not to be mirrored at all.

(4) laggy mirrors: If daytime bandwidth is an issue, and you're ok
with the lag, you can postpone mirroring to night times instead of
with every push.  The actual mirroring is triggered with a simple
command -- you can write your cron jobs around that quite easily.

(5) autonomous mirrors: Your mirrors don't all have to be under your
control.  They can be owned by someone else and you negotiate what
repos you'll mirror for each other.  For example, an open source
project may find a "donor" that is willing to mirror a few
highly-trafficked repos and make them available via git:// or http://

----

We use all these features (except the last one; it's not pertinent to
our setup), and things have been humming along for a few weeks now.

If you have any questions not answered by the documentation[1], feel
free to email me.

[1]: http://sitaramc.github.com/gitolite/doc/mirroring.html

-- 
Sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


More information about the git-announce mailing list