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

[Nathaniel Smith]

On Mon, Nov 29, 2004 at 10:10:02AM +0200, Oren Ben-Kiki wrote:
> 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"...

No, if you read the code, you'll see that it's implemented as finding
the common ancestor A, calculating the changeset from A -> E,
_reversing that_ to produce E -> A, and then concatenating it to the
changeset A -> C, to get E -> C, which gets merged with E -> wc.

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

Hmm, the doc won't help you, since this behavior is brand new and
possibly undocumented (?).  The doc is describing the behavior of
update when you don't give an argument, which is, given a revision
graph like

A -> B -> C -> D
           \
            working copy

find the last "good" (by some criteria) revision that's an ancestor of
the current base.  So this starts at C, searches down to find D, and
merges C -> wc and C -> D.  Same operation, really, just simpler
to implement because we don't have to play around with reversing
changesets to construct the changeset we want.

[re: saving the history of merges in the revision graph:]
> The main reason you do this is for documenting the "geneology" of 
> the revision. 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.

Traditionally this is the sort of reason that people keep
ChangeLog files... hmm.  We have some precedence for saving this sort
of information in automatically generated changelog certs; both
"merge" and "propagate" record what happened this way.  (This actually
records more information than the revision graph itself does; so the
graph might say A and B merged to make C, while the comment says that
this was a propagate from branch Foo to branch Bar.)

It does make sense to store this information computer-readable; main
choices for that in Monotone would be 1) a new cert, 2) in the
revision format (as you suggest), or 3) in the tree itself.  (3)
leads to unbounded growth of the tree, like I guess some other VCs
have to contend with, so I don't like it.  Between (1) and (2) though,
I don't think I have anything really intelligent to say right now.

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

I meant, if I do "cp foo new-file-initially-similar-to-foo", then I
now have to remember to go reset the id in the new file (my tool will
presumably check for duplicates and remind me at some point, but it's
still annoying).  Similar things happen if splitting a file up into
pieces, etc.

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender