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

[Oren Ben-Kiki]

On Monday 29 November 2004 00:50, Nathaniel Smith wrote:
> > 1. Cherry-picking:
> >
> > [...]
>
> 'update' on mainline does this... if you have
>
> A --> B --> C
>  \
>   D --> E
>          \
>           working copy
>
> then 'monotone update $C' will perform a merge of your working copy
> and C, using E as the common ancestor, writing the result into your
> working copy.

I thought "update" will use "A" as the common ancestor, merging "C" into 
the current working copy - completey ignoring "B", "D" and "E"...

> ... this is exactly how 'update' on mainline can "move" your changes
> to be against a different revision, and the way of doing
> cherrypicking that I've been advocating. :-)

I must be missing something here. Maybe "update" doesn't do what I think 
it does... but re-reading the doc I'm get the impression it uses "A" as 
the common ancestor. In contrast, what I propose is using *B* "as if" 
it was the ancestor of the working copy version - which on the face of 
it is rather crazy. No system I know offers it... Can you elaborate?

> >     D --> B --> F --> G --> C
> >       \    \.............../
> >        \           \
> >         \-> A ------> E
>
> This part is different, though.  I've been really hesitant to get
> into trying to record cherrypicks in the revision graph, because it
> feels like one of those problems whose "solution" suddenly makes your
> system an order of magnitude more complex, and you never do hunt down
> all the edge cases.  But, maybe not... can you elaborate on this
> point more? How do you write down this "dotted edge", and do later
> operations automatically do clever things with it?  What sort of
> clever things?

From what I saw in the documentation, in the revision history, you have 
an "old-revision" entry. If you did a "merge", I expect there would be 
more than one such entry, reflecting the merge. In contrast, an 
"update" changes the entry to a new value. Right so far?

Now, if you did a "patch", you'd have a second kind of entry:

 from-revision: <start-of-patch>
 to-revision: <result-of-patch>

Or something along these lines. This has little effect on the rest of 
the system, because you still use SHAs and so on to track what the 
changes actually were. So I don't see that the act of 
recording/displaying patches complicates any current operation.

The main reason you do this is for documenting the "geneology" of 
therevision. If I applied the "fix memory leak" patch from the unstable 
branch into the stable one, I want it to be on record, and not as some 
human-provided text buried in a comment somewhere - it should be 
visible in the graph. So the sort of "clever things" you can do is run 
queries, like "show me revisions that incroporated the memory leak 
patch", or answering questions like "was the memory leak patch 
incroporated into this revision?".

This is vital for managing such a system - imagine doing a branched 
multi-developer distributed project, and not being able to tell whether 
you did or did not incroporate the "fix memory leak" patch from the 
"unstable" to the "stable" branch without actually examining the 
code... shudder.

> > 2. File renames.
> > [...]
> > What we came up with was
>
> [Arch-style file/directory ids, with some heuristics for detecting
> renames]

Yes. IMVHO, this is one thing Arch got right. Except that AFAIK they 
don't do the "I guess you did a move" using diff sizes and cached 
external uid files. Then again, I haven't looked at it in great detail 
for a while.

> > Any file which does contain the UID pattern is
> > automatically confirmed as a source file, and so on.
>
> That doesn't work, actually, editor backup files (foo.c~ and the
> like) will always have the UID pattern.  Arch has machinery for
> dealing with all this...

Yes, you use regexps to excluse such files.

> > There's another, bonus advantage hidden here. Remember the
> > cherry-picking problem? To solve it, we had to do a 3-way merge.
> > And to do that, we had to know, for each file in my version, what
> > is the name of this file in the two...
>
> This is pretty much the crux of the debate about "changesets" that's
> been on the list recently -- whether it should be possible to apply a
> changeset without backtracking through history.  It seems to have a
> large component of taste -- what's your opinion of these random tags
> cluttering up your source files and source directories, would you
> rather muck around in your editor or with calls to the VC, etc.  I'm
> not sure that performance is really relevant.

Well, as a general principle thing, I tend to think that the more 
"stand-alone" changesets are, the more robust the system is. But I 
agree; put the performance issue aside.

As for cluttering the source files: Source files already have 
"boilerplate" at the start - copyright notices and that sort of thing - 
so another line isn't a problem, especially when I can generate it by 
typing ".:!mkuid" and never worry about it again. Finally, you don't 
have to add a uid line in your source file, there's always "plan 
B" (keeping a .monotone-uid/<file>.uid file near the source) which is 
pretty invisible, is generated automatically for you (when you do an 
"add") and also works. So different tastes are accomodated (to some 
extent).

> ... Besides which, the work involved in running "monotone mv foo
> bar" is hardly an order of magnitude more than the work involved in
> running "mv foo bar" :-)

If I move it it in a GUI, I have to get to the CLI and type a "monotone 
rename" command, including at least one (and probably two) longish path 
name I can't cut&paste from the GUI. Ugh.

And remembering when to call "monotone mv" vs. "mv" is also a PITA. I 
guess I could write a shell wrapper for "mv" that would check if I'm in 
a Monotone directory and I'm moving a source file and call "monotone 
mv" instead of "mv"... but that's a hack.

> When I copy or split a file/directory in Arch, I have 
> to go muck around with the tags by hand, to ensure that they're all
> unique,

Huh? Using some 'mkuid' generating random many-bit ids prevents you from 
having to bother with all that. That's the whole point... Am I missing 
something?

> Arch has a concept of a "well-formed tree" -- one where 
> tags are unique and assigned -- which Monotone doesn't have to bother
> with, much.

I agree that there's some additional implementation complexity. But 
really, you have the same issue in Monotone:

> We do still have the concept of "well-formed tree" as, 
> all the files that are supposed to exist, do,

And all the existing source files are recognized by Monotone as such... 
This is exactly the same thing.

> The Arch solution partly just moves the issues around.

This is the law of "conservation of pain". You can shift it between file 
creation, rename, or merge/update/commit time - either way, its there.

> Guess I'd just like to see more evidence that this distinction is as
> critical as the proponents of tags make it out to be.

I wouldn't say "critical". I would say "important". Where you want your 
pain is, as you pointed out, a matter of taste. Personally, I'd rather 
have my pain in the form of a uid comment in source files.

In YAML, our policy is that when something boils down to a taste issue, 
we defer to the project's founder - that might seem as a perk, but its 
really a mixed blessing. But it does prevent things from being "stuck", 
or keep endlessly debating the issue. So, if I'm just re-opening a 
settled taste issue, my apologies, and I'll back off. All that said, I 
still like uid comments much better ;-)

> > 3. Merge tracking (a rather minor issue).
> >
> > Like Monotone, we viewed the history as a DAG. Work always begins
> > with some revision, so you get one edge for free. You get another
> > edge leading to your new revision every time you merge it with some
> > other revision. So far is common wisdom; I _think_ this is the way
> > Monotone does it, although the on-line documentation is silent on
> > the issue.
>
> Well, it's almost correct, but maybe a little confused.

Yes. I missed the difference between "update" and "merge", which solves 
this very neatly. That is, assuming "update" does what I think it does. 
Which I'm now not as certain about :-)

Have fun,

 Oren Ben-Kiki