On Fri, 2007-01-12 at 18:14 -0800, Nathaniel J. Smith wrote: > Anyway, the answer to your question is that I'm not proposing anything > at all change in monotone -- that's why I said at the beginning of the > writeup that my note had no practical consequences :-).
I think that merge behavior is one of the most crucial pieces of how a VCS behaves. Darcs is an example of this approach taken to extreme, and demonstrates how a solid theoretical basis for the merge can be viewed as "the" core design choice of a VCS. Having something equivalent for more traditional version control systems would be a real breakthrough IMVHO. As for practical implications - cherry picking can be defined in terms of a merge operation, as long as you *really* trust your merge :-) > We've > generally taken the line that the history graph should attempt to > model as closely as possible the user's intrinsic understanding of > "versioning a bunch of files", because this is the both the most > user-friendly and the most future-proof approach. (Sucks to build a > particular merge algorithm's assumptions into your hash-chained > history graph, and thus be stuck with that merge algorithm for a few > decades...) That's true. On the other hand, there's immense power to be gained from picking a powerful merge abstraction and running with it (again Darcs is a good example). > That said, I dunno, maybe someone will figure out how to use this kind > of stuff to improve VCS UI -- it's just some ideas, who knows what > will happen to them once they start wandering around in people's > heads... For starters, annotating the '#' with the list of candidate values immediately suggests an interface for conflict resolution. Also presumably the cases where "conflict" actually occurs would (hopefully) be more in line with user expectations. And then there are the advanced features you could build on top of this (like cherry-picking). These all require that the chosen merge abstraction be really solid, which translates to trying to poke theoretical holes in it, and then trying it in practice for a while, until sufficient confidence is reached. Most VCS don't trust their merge method (for good reason). On the down side, this restrict their power; on the up side, they allow plugging in different merge algorithms, so it would be possible to implement and test deterministic *-merge in them to see how well it works in practice. Monotone is a particularly good platform for this because it is based on solid abstractions in other areas (what is a version, what is a branch, etc.) _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel