[darcs-users] when darcs is slow, it is really really slow

[David Roundy]

On Sat, May 21, 2005 at 10:34:23AM +0200, Vigor van Ort wrote:
> On 5/20/05, Tommy Pettersson <ptp at lysator.liu.se> wrote:
> > Did you ever sync the snapshot repo and the source code repo, that is,
> > did the patches that updates the line numbers in the code repo get
> > pulled to the snapshot repo so that new snapshot update changes was
> > made against newer line numbers?
> 
> Hmm..  No, the snapshot repo is basically the vendor branch -- it only
> contains changes from the vendor, I never pull into the snapshot repo
> from local mods.  I do submit changes back to the vendor, and so they
> will eventually become incorporated in future snapshots.

This is something darcs isn't going to do well.  Darcs is really designed
to work with darcs and other collaborators using darcs.  Working the way
you are is pretty much guaranteed not to work, and that's not going to
change.  What you want is a tree-based SCM, not a patch-based SCM, since
you're interfacing with a series of trees, not a series of patches.

On the other hand, you might be able to hack around things to merge your
changes with upstream from time to time.  If you ever get to a state where
your local tree matches upstream, you could pull all your changes into the
vendor tree, which would be helpful.

> > I ask, because this would be a typical case where darcs gets
> > exponential if you don't, and it's not so much darcs fault as
> > the nature of the complexity of the growing merge situation
> > that's built up this way.
> 
> I've been doing this for months in another SCM system, and the merges
> never took more then a few seconds..   Not only that, but it produced
> better results as well.  The last time I managed a merge of line
> number changes, the results were pretty bad.  There were lots of lines
> marked as conflicts which had only 1 option.  Eg, I had many entries
> like this:
> 
> v v v v v v v
> modified text here
> ^ ^ ^ ^ ^ ^ ^
> 
> (no ************** separator and second option at all).  I wrote a
> small perl script to fix them rather then do it by hand..

This is because you've got a conflict with an identical change.  Darcs
doesn't know that the changes don't "really" involve a conflict.  If the
two patches had both been

hunk
-  total_options = 10
+  total_options = 11

Then the correct merge probably would result in "total_options 12", but
darcs doesn't know, so it flags it as a conflict.
-- 
David Roundy
http://www.darcs.net