Re: [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking...

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Thu, 25 Nov 2004 17:14:30 +0000, Bruce Stephens 
<address@hidden> said:

monotone> Richard Levitte - VMS Whacker <address@hidden> writes:
monotone> 
monotone> > Is it necessary to record some kind of information about this event
monotone> > in the database?
monotone> 
monotone> I think so.  There's some merit in storing this simply for
monotone> documentation purposes, but Arch also uses it.  
monotone> 
monotone> For example, if you subsequently do a star-merge (or
monotone> presumably other such merges) from that branch, Arch will
monotone> start from the changeset after the last cherrypicked
monotone> changeset.  (I'm not quite sure how it does it, exactly, but
monotone> someone said it did (I've never had occasion to use the
monotone> feature).)

Hmm, I'm not really well acquainted with arch (there are just too many
ways to do every darn thing!!!), so I can't really say I know exactly
what star-merge does.  If I was to implement a merge that supports the
presence of cherrypicked patches, I'd still start with the same common
ancestor as usual, but when applying changes along the edge of the
branch I'm merging from (so to say), I'd skip over the changesets that
have been cherrypicked.  Could that be what arch does?

Either way, when thinking in this way, it does make sense to record
what has been cherrypicked.

monotone> > I could see that the result might have a cert for each
monotone> > applied patch, to express what has already been applied,
monotone> > is there more that needs being recorded?  I could imagine
monotone> > 'monotone agraph' could use that extra information and
monotone> > generate another type of arrow in the graph, maybe dotted?
monotone> 
monotone> That sounds about right.  I believe that's what Arch does:
monotone> every changeset has a patch log with a New-patches: field
monotone> listing all the patches that have contributed to that new
monotone> changeset (the previous revision is assumed).

OK.  After all, since we do have the concept of certs, this seems to
be a good way to use them.

monotone> There's probably multiple ways of engineering this, and I
monotone> doubt the way that Arch does it is optimal (even for Arch).
monotone> For example, maybe it would be better to have a way to
monotone> indicate that some changesets are inappropriate for the
monotone> current branch (so rather than picking changesets, you'd
monotone> exclude particular changesets, and then propagate).

Command name ideas:

 cherrypicking:                 monotone transplant ID [BRANCH]
 disallow certain revisions:    monotone disallow transplant ID [BRANCH]

The second command is quite tricky, because there's really no place to
put a cert for disallowed IDs.

monotone> And maybe it would be useful to give a way to indicate
monotone> dependency, so it would be awkward to cherrypick a
monotone> particular changeset that really depends on others (monotone
monotone> would by default drag in the dependencies too).

*eeeep*

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis