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

[Bruce Stephens]

Oren Ben-Kiki <address@hidden> writes:

[...]

> 1. Cherry-picking:

[...]

> At any rate, we spent some time thinking about it, and I came up with 
> the following insight:
>
>     If you have a good 3-way merge, you can "cherry-pick" *anything*.
>
> (A "good" 3-way merge does not complain if the same change in both 
> branches. That is, it doesn't complain that "deleting line 7 conflicts 
> with deleting line 7" or "renaming foo to bar conflicts with renaming 
> foo to bar").

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.  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.

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.

[...]

> Could it be that simple? "Everybody knows" that applying patches 
> requires doing messy things with histories and deltas, otherwise 
> patches get applied more than once and so on. Well... It _is_ this 
> simple.

Yeah, but does it actually work?

[...]

> 2. File renames.
>
> File renames are by far the most annoying part of having to deal with a 
> version control system. If I rename a "foo" variable to "bar", I don't 
> have to tell the version control about it. But if I rename a file, I do 
> need to. Ugh.

Is that in fact so annoying?  As far as I can tell, it isn't.  I don't
find it that significant, and the two solutions you give have been
implemented in GNU Arch (it calls them tagline and explicit).  This
described explicit,
<http://www.gnu.org/software/gnu-arch/tutorial/inventory-ids.html#Inventory_Ids_for_Source>.
There's also a way to embed the tag in the file (in which case you
don't need to use "tla move".

And GNU Arch was one of the first of the new free version control
systems to reach usability, and nobody else seems to have taken up the
idea of embedding tag ids in files.  Or even the idea of having a
stable file id of any kind.  Presumably almost everyone knows of the
idea, but it's been rejected, for whatever reasons.

[...]

> 3. Merge tracking (a rather minor issue).

[...]

>     A --> B
>       \-> C
>
> However, suppose I merge with revision C _before_ I commit B. The graph 
> will look like this:
>
>     A --> C -\
>       \-------> B

How would I merge with C before committing B?  Presumably I'd have to
use update (since presumably C is in a working tree somewhere, because
I haven't committed it yet).  In which case when I do commit C, the
graph will already look like this:

>     A --> C --> B

My guess is that the same would be true of most version control
systems.

monotone is a little different in that two people can both commit B
and C based on A (without either creating a separate branch).  You
just need to merge the branch heads in order to get a unique latest
revision on that branch.