Hi guys, I've also been asked to take a look at this issue, but my time is still a bit iffy and I'd be more comfortable with Ganesh doing it if he's available.
That said, I'll contribute some minor stuff just tackling the fringes of this patch. I noticed that there was some uncertainty about what checkpoint patches were. Even though this is likely redundant and outdated, I've begun noting some stuff down on http://wiki.darcs.net/Checkpoints. Hopefully others who know about checkpoints or learning about them can jump in. I don't think checkpoints are anything particularly scary. As far as I understand they are just the mechanism by which darcs get --partial works. I think a checkpoint patch is just a patch that has the same cumulative effect as a set of patches under a given tag. That's all there is to it. Rather than fetching and applying a bunch of patches, you apply the one checkpoint patch that leaps from point A to point Z without any of the intervening changes. For example, if you had named patch 1: move f g, followed by named patch 2: move g h, the checkpoint patch created for it would be 'move f h'. It's a giant coalescing operation! If you have a copy of old darcs lying around, try making a checkpoint patch and see. In fact, make two in succession so that you can see how one checkpoint builds off the last state. So we're no longer creating new checkpoints from Darcs 2.3 on. The question I wanted to ask myself in this leg of the review is if we do away with the code in Darcs.Repository.DarcsRepo that manipulates the checkpoint inventory. I guess the only reason this code would be useful is if you were to either unpull/obliterate a tag. Perhaps that provides some decision-making context? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpXd5hZ0p7tc.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
