Hi Michael, >> As per previous mails in the thread, darcs semantics currently prevent >> editing patch metadata without changing the identity of both implicit >> and explicit dependencies. >> > > I understand how the identity of ask-deps dependencies must change (since > they're recorded as references to patchinfo). I don't see how other > dependencies must change. Can you provide an example? Ignoring ask-deps > dependencies, every scenario I've thought of can allow deep metadata > changes without affecting any other patches. > > >> Note that if you can't commute patches to >> the front then there is a stack of dependencies that would need to have >> their identity changed when editing the underlying patch. >> > > Sometimes that's true, but it doesn't seem to be true in the general (or > common) case. Can you provide an example so I can see what I'm missing? > > Coalescing two adjacent patches seems to be a safe operation (assuming no > patchinfo changes) because the coalesce has no net effect on the filesystem > on which subsequent patches operate. As far as subsequent patches are > concerned, the coalesce was a noop. I'm probably missing something > obvious, so a counterexample would be great. > For both points, there is at least one common reason: darcs' algorithms rely on the fact that if two repositories R1 and R2 share a patch p, then they also share any patch p depends on. If you don't ensure that invariant, then pull for instance will start doing weird stuff. For instance, if r1 and r2 have patches abc with c implicitely depending on a and b, if in r1 we coalesce a and b into [ab], what happens when we pull from r1 into r2? Should we offer [ab]? How would we merge it? What about the case where r1 and r2 coalesced a with b1 and b2 which conflict?
Florent _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
