On Sun, Aug 12, 2007 at 02:46:19PM +0200, Eric Y. Kow wrote: > On Tue, Aug 07, 2007 at 18:05:07 -0700, David Roundy wrote: > > This is another one of those semantics-altering changes, like the > > commute_nameconflict patch I just sent. In this case, I'm changing > > it so that a file rename patch depends on the addition of that file. > > Makes sense to me (how was the previous behaviour supposed to reduce > conflicts?)
The thought was that any time a commute fails, it leads to a dependency. But no, it didn't do much. > In any case, I don't forsee this actually biting anyone. > > For that matter, I guess that when we talk about 'danger'; we're > referring to at least two things: (1) the behaviour is bad in itself and > (2) it does evil things with previously existing repositories. Were you > talking about one of these things in particular? I would guess the > latter, although naively, it seems that restricting the commutability > (commutativity?) of patches 'only' results in people having more trouble > performing merges than before, and cherry picking being less flexible. > Am I missing something important? Yes, it's mostly (2) we're talking about. The real danger is that *whenever* you change merge behavior, there's a possibility of introducing repository corruption, if our users are mixing the use of two different versions of darcs. Which is why we don't want to change things like this if there are "live" instances where it has had an effect. Where by "live", I mean that these involve patches that are still getting actively merged. An old, historical merge where this had an effect is no problem. -- David Roundy Department of Physics Oregon State University
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
