Gitolite v2.1 and mirroring features

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

Sitaram Chamarty wrote on 30 Sep 2011

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s