[darcs-users] Darcs slow when commuting mergers -- continued

[David Roundy]

On Thu, Oct 28, 2004 at 10:00:08PM +0200, Juliusz Chroboczek wrote:
> David,
> 
> Still, I think there's something wrong.
> 
> I've waited for the conflicting merge to commute all the way from the
> stable branch to head, but now I'm getting 10+ minutes of CPU grinding
> for every merge that comes from the stable branch.
> 
> Right now, I'm waiting for a merge for the documentation (dated 26
> October, ``Documentation update: three places now'').  This is a
> trivial change to polipo.texi.  No patch on the unstable branch
> touches the documentation -- the commute should not involve anything
> non-trivial with respect to mergers.
> 
> Perhaps Darcs isn't special-cased for commuting patches that don't
> have any file in common?

Hmmmm.  There is a special case that should cover this situation, which
uses the "is_filepatch_merger" function.  The only potential issue I could
see is that the mergers could just be so darn big (they do grow
exponentially) that even checking to see what files they touch is
expensive!

It's more likely that the expense is coming from determining the
appropriate context, which may involve very nasty commutation.  If you push
from (left patches first)

abcdefg

to

ABCDEFGabcdef

darcs will have to commute ABCDEFG with abcdef before it can merge the 'g'
patch in.  This can be very expensive.  A solution would be reordering the
repository, but then what if someone who has a repository holding

ABCDEFGH

wants to push?

I guess (if I understand this scenario correctly) the moral is that if
you're pushing non-conflicting patches, it's probably faster to do many of
them at once, at least if they don't touch the conflicted files.
-- 
David Roundy
http://www.abridgegame.org