{"thread":{"id":"28532","subject":"[ANNOUNCE] Gitolite v2.1 and mirroring features","startedAt":"2011-09-30T06:44:33Z","lastAt":"2011-09-30T06:44:33Z","messageCount":1,"participants":["Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176554","messageId":"CAMK1S_j3dK1m5j2B3yzW_ofyL5WSwE4+96wusS4FkwbTgkTZTA@mail.gmail.com","threadId":"28532","inReplyTo":null,"subject":"[ANNOUNCE] Gitolite v2.1 and mirroring features","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2011-09-30T06:44:33Z","receivedAt":"2011-09-30T06:44:33Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Hello all,\n\nI've kinda stopped sending \"announce\" emails for all the little\nfeatures and enhancements that happen to gitolite, but this one seemed\nbig enough and important enough to send one out to this list.\n\nGitolite v2.1 now does mirroring much more flexibly and powerfully\nthan the old, rather naive, setup.\n\nMost of the impetus for these changes came from a rather large product\ndevelopment group within TCS, the company I work for -- many cities,\noffices, servers, repos, and developers.\n\nHere are the highlights:\n\n(1) the \"NUMA\" thing: Different repos can now be mastered on different\nservers, depending on which city/office has the most developers for\n*that* project.\n\nThis was the single biggest motivator for the new mirroring code; the\nrest of the cool stuff just happened along.\n\n(2) almost as good as \"active-active\" mirroring: If the \"master\"\nserver trusts the authentication performed by the \"slave\" server, you\ncan have the slave internally redirect a \"git push\" to the correct\nmaster.\n\nWith this, developers don't have to remember which repo is mastered\nwhere, use different 'pushurl's, etc.  They just do *everything* with\ntheir local mirror and let the system deal with it.  (You can even\nchange which server is \"master\" and people don't even need to know it\nhas changed!)\n\n(3) partial mirrors and local repos: A server doesn't have to carry\n*all* the repos in the system -- it can choose to carry only some.\n\nIn our case it was often because there were no developers for that\nproject in that office, but there could be other reasons.  Server\nload/resource constraints, legal/jurisdictional issues, server in a\nnon-free country and repo has crypto code ;-) etc.\n\nSimilarly, a server can have repos that it wants to keep purely local\n-- not to be mirrored at all.\n\n(4) laggy mirrors: If daytime bandwidth is an issue, and you're ok\nwith the lag, you can postpone mirroring to night times instead of\nwith every push.  The actual mirroring is triggered with a simple\ncommand -- you can write your cron jobs around that quite easily.\n\n(5) autonomous mirrors: Your mirrors don't all have to be under your\ncontrol.  They can be owned by someone else and you negotiate what\nrepos you'll mirror for each other.  For example, an open source\nproject may find a \"donor\" that is willing to mirror a few\nhighly-trafficked repos and make them available via git:// or http://\n\n----\n\nWe use all these features (except the last one; it's not pertinent to\nour setup), and things have been humming along for a few weeks now.\n\nIf you have any questions not answered by the documentation[1], feel\nfree to email me.\n\n[1]: http://sitaramc.github.com/gitolite/doc/mirroring.html\n\n-- \nSitaram\n"}]}