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

[Bruce Stephens]

Richard Levitte - VMS Whacker <address@hidden> writes:

[...]

> What exactly are we supposed to accomplish with cherrypicking?  As
> far as I udnerstand the idea in arch, it's basically picking one or
> several patches (diffs, manifests, revisions?) and apply them on
> whatever you currently have in your working directory, possibly
> including a commit directly after.

I think that's the essence of it, yes.

> Is it necessary to record some kind of information about this event
> in the database?

I think so.  There's some merit in storing this simply for
documentation purposes, but Arch also uses it.  

For example, if you subsequently do a star-merge (or presumably other
such merges) from that branch, Arch will start from the changeset
after the last cherrypicked changeset.  (I'm not quite sure how it
does it, exactly, but someone said it did (I've never had occasion to
use the feature).)

> I could see that the result might have a cert for each applied
> patch, to express what has already been applied, is there more that
> needs being recorded?  I could imagine 'monotone agraph' could use
> that extra information and generate another type of arrow in the
> graph, maybe dotted?

That sounds about right.  I believe that's what Arch does: every
changeset has a patch log with a New-patches: field listing all the
patches that have contributed to that new changeset (the previous
revision is assumed).


I think the overall functionality that I'd want is to be able to
propate bits of a branch to my working directory, and for that to be
remembered so that subsequent propagates won't (by default) drag in
patches I've indicated I'm not interested in.

There's probably multiple ways of engineering this, and I doubt the
way that Arch does it is optimal (even for Arch).  For example, maybe
it would be better to have a way to indicate that some changesets are
inappropriate for the current branch (so rather than picking
changesets, you'd exclude particular changesets, and then propagate).
And maybe it would be useful to give a way to indicate dependency, so
it would be awkward to cherrypick a particular changeset that really
depends on others (monotone would by default drag in the dependencies
too).