On Fri, Jan 16, 2009 at 1:07 AM, Grant Husbands <[email protected]> wrote: > This has had surprisingly little conversation, so:
I read this list on gmane, so please cc me :) > Jean-Philippe, Anders & Petter wrote: >> There should be no conflicting patches! > > I don't believe that this is true. Conflicts (and dependencies) are a > useful part of this sort of version control system, IMHO. The > approximation that a patch that touches a line depends on or conflicts > with others that touch the same line is quite often true and is useful > for the user to be informed of. In my experience, it has offered a > reasonable approximation of the actual dependencies between two > patches. There are motivations for the decision: 1. While "user-level" conflicts can indeed exist, and should be reported, "internal" conflicts are just a nuisance. Let's suppose you have patches that are "mostly" not conflicting, but in a small part of the code have an overlap. Our system allows them to be combined, as its normal mode of operation. The overlap will be notified as such, but the system does not get "in your way" if you want to try this and fix it with a further patch. 2. Cherry-picking or rollbacking /never/ fails. This is of course in the sense of point 1. above, and can even be considered a corollary of 1. 3. Additionally we chose a representation for patches which is independent of the context, which means that fiddling with the history becomes very efficient. In fact, this "context-dependent representation" is perhaps the key point. Once you have this you get conflict-free-ness automatically. 4. Finally, I think that the "theory" backing up our system is a lot simpler than that of darcs. This alone might make it worth considering. > There are situations in which it the dependency/conflict is > unsuitable, of course, and some of these could be corrected. One of > the primary examples is that of an indentation or other > non-meaning-changing whitespace alteration. I occasionally find myself > intentionally leaving some code incorrectly indented, in order to not > cause artificial dependencies. However, I feel that the answer to this > would be to introduce an indentation/whitespace patch type. Other, > similar problems have similar answers. > > The problems Darcs has with conflicts are unlikely to be due to the > decision that patches can conflict or depend on each other; it is more > likely that the way Darcs handles conflicts is insufficient. My take is that the improvement should take a form similar to what we propose :) >> all patches commute. > > Why should all patches commute, if the external representation still > has the same conflicts as the current Darcs representation? In my experience, darcs sometimes prevents cherry picking, etc. in case of conflicts, which I see as an annoyance. See my motivations 1. and 2. above. > Further, > if you do have missing patches, I believe you can no longer present > the user with a reasonable view of the changes. For example, if the > user pulls a patch that changes a line from "a" to "b" and another > that changes the same line from "c" to "d", what could they be told or > do? You can always choose /some/ representation for this kind of cases. e.g: <<<< a |||| b >>>> c |||| d This particular representation might by bad, but my point is that it is not difficult to come-up with something. Fixing this sort of conflict (as conflict) could be done by either 1. replacing the text by what you want 2. applying "missing" patches 3. fiddling directly with the internal representation. >> As part of a master-level project, two students of mine have implemented >> this idea in a prototype [1], and the report can be found here [2]. > > The report was quite interesting and quite clearly explained why other > version control systems have trouble with merges that are trivial > under the new system and Darcs. However, it did not seem to present > real world examples of the effects of the new patch representation. > For example, is the user warned when they try to combine a patch from > a file with lines (a,e) to a file with lines (a,c,e) with a patch that > goes from (a,e) to (a,n,t,e)? It is a intuitively a conflict, but my > impression is that the conflict-free RCS will give a file with lines > (a,n,c,t,e), without warning. In some cases our system will happily produce an output, whereas you might want to see a warning. This is future work :) However, I'd like to point out that in these cases your editor/compiler/testsuite will most definitely report a problem. Having a VC-level warning is "just" faster/earlier in the chain. Cheers, JP. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
