On Wed, December 19, 2007 10:12 am, David Brown wrote: > On Wed, Dec 19, 2007 at 09:39:46AM -0800, Lan Barnes wrote: > >>>>(I was poking around on the mercurial webpages today and discovered >>>> this.) >>> >>> I'm curious where you got this, since it is blatantly false. >> >>OK, who'm I gonna believe here, SJS or Dave? ;-) > > Both, actually. I didn't read far enough, and trimmed the part where SJS > explains that it foists the merging off to an external program. > > What I was trying to explain is there are two parts of the merge problem. > One is how to merge between two (or more) files and a common ancestor. > There are numerous programs that do this, from 'merge' to various gui-type > tools. > > The harder problem for most revision control systems is figuring out what > that common ancestor is. Without storing meta data about how past merges > were done, some just can't figure out what a good ancestor to use is. > > Most of the modern revision systems don't try to do the 3-way merge > themselves, since there are plenty of tools to do it. There's always the > Perforce approach, which seems to be to implement everything itself, only > poorly. Even the diff output it generates has to be mangled before it is > valid input for patch. > > Dave >
>From a developer's POV you're right, but it's an oversimplification. Many merges can and should be resolved by "accept theirs" or "accept mine." -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
