[darcs-devel] darcs patch: fix ordering mistyping in
sift_for_pending. (and 2 more)
Eric Y. Kow
eric.kow at gmail.com
Sun Aug 12 15:11:42 UTC 2007
> Tue Aug 7 17:52:51 PDT 2007 David Roundy <droundy at darcs.net>
> * fix bug that revealed itself in optimize --reorder on unstable repo.
I'm pushing this as well, although I don't fully understand it.
I've been looking at the apply command to get a better idea what happens
in pending when you apply a patch (via darcs apply).
The idea is that applying a patch may may have consequences in the
working directory beyond those it already has in the pristine version.
We want to add these consequences into the pending patch. To accomplish
this, we make a 'pending' sandwich. It consists of
* top : the inverse of (the patch as merged with pristine)
* middle : the original pending patch
* bottom : the patch (as merged with the working directory)
We then 'sift' the whole thing to get the new pending patch. I don't
fully understand sifting. I'm guessing that it consists in looking for
changes that can't be inferred from diff or the changes that these
depend on. Part of sifting involves simplifying our pending sandwich
(try_to_shrink). I have not really thought about this simplification
(it involves commuting and coalescing). In either case, David's patch
makes this simplification more agressive by looking for and eliminating
"auto-cancellations" (my crappy terminology). An auto-cancellation is
* A A^ (a patch followed by immediately by its inverse) or
* A X A^ where X is an auto-cancellation
This changes does appear to be harmless -- it's just in the pending
patch anyway -- and we only remove these A A^ things when there is
nothing in between. Interestingly, its effect on optimize is not
really related to the 'pending sandwich' story. It's just that
(before David's optimize optimize patch), optimize called
tentativelyRemovePatches (which prepends inverse patches to pending)
followed by tentativelyAddPatches (which prepends patches to pending).
And there we have auto-cancellations... sometimes... (because they
are sometimes simplified away by the original shrink code?)
Incidentally, this patch also 'solves' the issue494 stuff, although I
don't know if it is an actual solution or just something which hides the
Anyway, my head is spinning now, but let me know if I've said anything
silly. The patch goes in.
Eric Kow http://www.loria.fr/~kow
PGP Key ID: 08AC04F9 Merci de corriger mon français.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070812/4bdeef15/attachment.pgp
More information about the darcs-devel