gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: darcs vs tla


From: Robert Collins
Subject: Re: [Gnu-arch-users] Re: darcs vs tla
Date: Sat, 13 Nov 2004 11:37:38 +1100

On Tue, 2004-11-09 at 10:21 +0000, Catalin Marinas wrote:
> There is already a darcs Linux repository at http://darcs.net/linux.
> This proves that, if you have a powerful machine (1GB RAM prefered), you
> could use darcs with the Linux kernel.
> 
> I suspect arch would also be a bit slow for a rate of 50 patches/day.

I have a checkout here of goerzens linux tree. Using roughly tla 1.3,
changes (which is the bulk of time for commit) took:
(cold): 10m57s
(hot): 12m15

I'm pretty sure the inode signatures where out of date in that tree. So
I grabbed a clean copy, and applied the same delta:
(cold): 0m14s
(hot):  0m7s

I have 1Gb ram and a 5400rpm hard drive. tla peaked at 100M in virt and
res columns in top for both copies of the linux tree.

That says that I can commit changes to a linux source tree in 20-30
seconds top. If thats slow performance, you've pretty high standards for
performance. 

>  It
> might take a few minutes for each commit operation. You can optimise
> this by hard-linking the tree to the revision library but many of the
> links would be lost in few weeks of applying patches. 

Note that the above performance metrics are from not hardlinked trees.

In a hardlinked tree, with the same trivial one changed file, I see:
(cold): 0m45s
(hot): 0m14s

All the times I've given are the real times, not user or system. Oh, and
cold is just the first run, I've not done anything to flush the cache
etc.

Finally, IIRC the performance data from when I was profiling this, we do
3* as many stats as required, and correcting that massively improves hot
performance.

> One other thing I like in darcs is the possibility of cherry-picking
> changes from any related repository because a merge operation doesn't
> lose individual changesets. Arch generates a single patch after a
> replay/commit sequence, no matter how many patches were applied. Anyway,
> this is not a problem if you have a branching hierarchy and try to only
> merge changes from the parent branch.

Arch can do single patch merges, I wrote pure-merge.sh ages ago (2 years
I think) which does precisely that, automatically, but doesn't handle
all the cases of conflicts that can occur. Andrew Suffield and I
hammered out the algorithm for handling those, but no ones implemented
it in the intervening time. 

Rob

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]