It is funny how such a small and innocent looking change led to a series of
patches, some of them much less trivial.
I can't remember exactly how I noticed the broken move in our repos, perhaps I
just ran a check or repair in one of my clones and noticed that it now
"crashes". After I extended Prim.V1.applyAndTryToFixFL and doing lots of tests
and self-review to make sure this is really okay, I went ahead and repair'ed
screened on darcs.net, and I think the other repos, too (reviewed, releases).
Quite some time later I noticed that my clones had become slower on operations
like push and pull or with commands that support --not-in-remote. Furthermore,
a fresh clone with the new patches pulled of top did not show this behavior.
This vexxed me enough to investigate. Comparing the two repos I found that
their _darcs/inventories differed a lot, in particular the fresh clone had
much fewer inventories. So I looked into the upstream repos and saw that
screened has just a single inventory! This made me remember the repair
operation and indeed a quick look at the code in Darcs.Repository.Repair
revealed that repair throws away all Tagged sections (it worked on the result
of a patchSet2FL). So I fixed that. But then I had already repaired the repos
on darcs.net, so how to restore them to their old glory? This led me to add --
deep/--shallow options for optimize reorder, --deep having the effect of
creating inventories for all clean tags in the repo and also trying to make
all tags clean as long as that doesn't make an earlier tag unclean. Again,
after lots of testing and self-review, I ran this on on the repos on darcs.net
(this time I archived the old versions under /opt/darcs/old).
What is still missing is a variant of `darcs optimize reorder` that adapts an
existing repo to the inventory structure (and thus patch order) of its
upstream. Like a fresh clone with patches added/removed as required to mirror
the old clone, as I did manually when I first encountered the mysterious slow-
down. This should make use of packs if present in upstream. We could perhaps
try to detect situations which are suboptimal (during push and pull and such)
and issue a warning with a hint how to improve the situation.
This is related to my idea (still not realised) of a "safe mode" which does
not trust patch identities and instead requires patch content equality (via
content hashes, including inventory hashes), re-ordering patches locally if
necessary. This would reliably detect violations of the ident-commute law,
i.e. our assumption that re-ordering via commute is the only valid way that
patches can keep their identity (and vice versa). Realising this idea is
difficult because it means everything in Darcs.Patch.Depends must be
refactored, if not completely re-written.
|
