Petr, I know you're working on a bug in repair, and I had a thought today.
If your fixes to repair end up rewriting patches it could end up triggering bugs in get_common_and_uncommon. I have a write up of why it's bad to change the commutativity of patches buried in the issue description of issue27. Basically, if there are two branches and you rewrite the patches in one branch then operations between the two that use get_common_and_uncommon (most operations), could violate a darcs invariant. The invariant is that once a patch is created it will continue to commute the same way. Hopefully this gives you some ideas on how you will test your bug fix. One thing you could do is prove that repaired patches commute the same as the unrepaired ones. Thanks, Jason On Thu, Nov 6, 2008 at 3:58 AM, Petr Rockai <[EMAIL PROTECTED]> wrote: > Hi! > > This bundle further fixes the Repair stuff. I suppose the descriptions are > fairly self-explanatory, the first patch got pulled in through dependencies, > it's already part of the previous bundle. > > Yours, > Petr. > > Thu Nov 6 00:46:38 CET 2008 Petr Rockai <[EMAIL PROTECTED]> > * Refactor Repository.Repair.replayRepository to get rid of CanRepair. > > We now instead return the new (repaired) patchset that needs to be written > out > to the caller, and let them handle it. > > Thu Nov 6 11:15:57 CET 2008 Petr Rockai <[EMAIL PROTECTED]> > * Fix Repair.applyAndFix. > > The way I have got the recursion versus syncing slurpies backwards is > actually > pretty embarassing. We also use syncSlurpy to avoid unneccessary (likely > slow) > syncs while keeping memory use at bay. This fix should make repair and check > run much faster in much less memory. > > Thu Nov 6 11:21:01 CET 2008 Petr Rockai <[EMAIL PROTECTED]> > * Introduce syncSlurpy, that syncs slurpy to disk as needed. > > syncSlurpy takes an IO action that does the actual syncing, but only calls it > when neccessary to prevent memory blowups. It is fairly cheap to call often > (ie. after every applied patch). The sync threshold is currently hardcoded to > ~100M. > > > _______________________________________________ > darcs-users mailing list > [email protected] > http://lists.osuosl.org/mailman/listinfo/darcs-users > > _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
