[darcs-users] Re: Decoupling patch ids from metadata [was: Fixing a repo with duplicate patches]

[David Roundy]

On Sat, Dec 23, 2006 at 09:49:16PM +0100, Benjamin Franksen wrote:
> Juliusz Chroboczek wrote:
> >>> Why does darcs allow me to create a corrupt repo?  Is there any way
> >>> to prevent this from happening in the first place?
> > 
> >> It's been a wishlist request for a while (I believe).  We don't want to
> >> have a complete check by default, since that's an O(N) process where N is
> >> the length of the repository history (unless we did something tricky),
> >> but a check at the most recent patches would catch most such mistakes,
> >> and be cheap.
> > 
> > We've discussed this at FOSDEM last, and you know I don't agree.
> > 
> > IMHO, the issue is with the way Darcs generates patch ids -- for some
> > reason, a patch id is generated as a hash of the patch metadata.
> > 
> > Now if you look at the properties that a patch id must have, there are
> > only two:
> > 
> >   (1) a patch id must be invariant w.r.t. commutation;
> >   (2) a patch id must be globally unique.
> > 
> > The current approach passes (2), but fails (1).  A simpler approach
> > would be to generte a patch id randomly; given a sufficiently large
> > space (and a little care in generating random numbers), this would
> > pass (1), and if the patch id is encoded in the patch itself, it would
> > also pass (2).
> 
> There is one downside to this:
> 
> Currently, if I convert two branches of a CVS repo with cvs2darcs, the
> generated darcs patches that are from the common history (= before the
> split point) of the two branches are the *same* patches (i.e. they have the
> same id). I find this is a very nice feature because it enables me to treat
> the resulting darcs repos as if they were 'real' darcs branches. This would
> be lost if patch ids are generated using random numbers.

We could have a flag to disable this, but since conversions of CVS repos
are precisely largest practical reason for adding the feature, it seems
like it might be best to add the new proposed feature, and make tailor
smart enough to keep track of common history (i.e. take a darcs repo and a
cvs branch as input, and keep whatever common history it can find).
-- 
David Roundy
http://www.darcs.net