monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc.


From: Oren Ben-Kiki
Subject: Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc.
Date: Mon, 29 Nov 2004 08:51:33 +0200
User-agent: KMail/1.7.1

> >     If you have a good 3-way merge, you can "cherry-pick"
> > *anything*.

On Monday 29 November 2004 00:19, Bruce Stephens wrote:
> This sounds rather similar to what CVS does.  I don't see it
> documented, but it's well known that "cvs update" will overlook
> changes that seem to have already been made.

Yes, a "good" 3-way merge is something we have today. That's sort of the 
point :-) Its use for "cherry-picking", however, is not something I've 
ever seen.

> A problem is that 
> that's line-based, and if one of the changes is an indentation
> change, then everything will conflict.  That seems to me to be the
> attraction of using history (or in darcs, a theory): you don't have
> to guess based on similarity of the text, since you have a record of
> exactly what was done.

In theory. In practice, Darcs will have the same problem with changing 
indentation as any other system. The only "patch" it has that's smarter 
than addition/deletion of lines is "s/foo/bar/g". Which is nice, but 
far from being a solve-all.

You could extend Darcs to support other types of changes - change 
indentation, reorder class members, move variable definition... in 
fact, you could throw all of Fowler's rafctoring book at it. So, a 
Darcs-like approach would be great if integrated with a refactoring 
browser (e.g., IntelliJ). But for a general-purpose version control 
system, I think its a dead-end. Personally, if I want to "s/foo/bar/g", 
I do that in VI, not in the command line. And I really can't imagine 
doing "reorder class members" in the command line... Ugh.

> I don't understand why you think that using history in a naive way
> would be complex.  It seems rather simple: you just take the
> line-based diffs for the changes you want to apply, and you try
> applying them.  There are complications with file momement, but not
> impossible ones.

The killer is "the changes you want to apply". Applying the patch "A -> 
B -> C -> D" this way would wreak havoc if you already applied "B -> 
C". That's where complexity kicks in, with a vengence; given the set of 
lines that changed between A and D, it is pure hell to "subtract" the 
line changes of "B -> C" so you can only apply the rest... or whatever. 
*This* is what the 3-way merge gives you for free.

> Yeah, but does it actually work?

There's only one way to find out :-)

> > File renames are by far the most annoying part of having to deal
> > with a version control system.

> Is that in fact so annoying?

Definitely. You can't do "monotone move" in a GUI - some people actually 
do use GUIs to manage their directory trees... And if you do a "big" 
reorganization of your code, having to report each change by hand to 
the version control system gets old very fast. And so on. Besides, it 
is like having to apply a choke when starting a car on a cold day, it 
practically screams for automation.

Have fun,

 Oren Ben-Kiki




reply via email to

[Prev in Thread] Current Thread [Next in Thread]