[Top][All Lists]
[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
- [Monotone-devel] Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/28
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/28
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc.,
Oren Ben-Kiki <=
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/29
- [Monotone-devel] Invariant failure on propagate., Jean Pierre LeJacq, 2004/11/29
- Re: [Monotone-devel] Invariant failure on propagate., Nathaniel Smith, 2004/11/29