Re: The annual git/svn discussion (was: Re: Minutes of the pkg-perl BoF at DebConf 10)
10 19:44, Jonas Smedegaard <firstname.lastname@example.org> wrote:
> On Mon, Aug 09, 2010 at 07:06:05PM +0200, Xavier Oswald wrote:
>> On 08:02 Mon 09 Aug , Tim Retout wrote:
>>> On 8 August 2010 07:27, Xavier Oswald <email@example.com> wrote:
>>> > On 23:35 Sat 07 Aug , Tim Retout wrote:
>>> >> I assumed we would want one git repository per package. Now, 1700 >>
>>> >> git repositories turns out to be quite difficult to make perform >> as
>>> >> quickly as a single svn trunk checkout.
Actually, this isn't as bad as I remember - I was about to post a rant
about people underestimating how difficult it was, but then decided to
re-test first. :)
First I added the ssh connection sharing stuff to the top of .ssh/config:
Then I created an mrconfig with about 300 git repositories from
collab-maint. These are probably not identical to Perl modules in
every way, but should be enough to test whether we can handle lots of
repositories. In the case of 'git fetch' with no changes I expect
there'll be no difference.
And then I ran "time mr -j10 update" after checking them out, and got:
mr update: finished (299 ok; 16 failed)
mr -j10 update 8.08s user 12.15s system 18% cpu 1:48.99 total
Which would suggest 1700 packages should take about 12 minutes for the
equivalent of 'svn up' in trunk when nothing much has changed.
For comparison, my svn up from this evening (which did have some changed stuff):
svn up 30.39s user 17.52s system 10% cpu 7:39.73 total
So git is perhaps 50% slower than svn in this scenario, which is
probably bearable. We should be able to speed this up using hacks.
We would still need to deal with problems like generating an mrconfig
after we added new repositories, and a new workflow, etc.
Tim Retout <firstname.lastname@example.org>