[Monotone-devel] Re: Synchronising changes in two branches WITHOUT the full history?

[Bruce Stephens]

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

[...]

> However, if I import a new 0.9.7-stable snapshot into the
> openssl.097.import branch, any subsequent propagations from that
> branch will include those changes.  This is OK when I propagate from
> openssl.097.import to openssl.097.rfc3820.  However, the further
> propagation from openssl.097.rfc3820 to openssl.098.rfc3820 will
> also contain those changes, and that's not necessarily a good thing,
> as there is some development going on in 0.9.7 that doesn't (yet)
> belong in 0.9.8.  That's where I get in trouble...

You want cherrypicking, which monotone doesn't yet support.  Arch
does, but (unless I've missed something) it doesn't really support
what you want.  That is, I can merge in a selection of changes from
some other branch, omitting those that I don't want (and it'll
remember that those have been merged), but it doesn't remember those
that I deliberately don't want to merge, so commands like star-merge
will happily try to merge in all the patches that I didn't merge
before.

In principle, I think monotone has suitable framework for doing this.
Once it has a good representation for changes, then it could support
adding certs to changes which could express things like "deliberately
omitted from branch ...".  The user interface will be challenging, and
probably it'll be useful to be able to remove at least some certs.
But in principle, I think monotone should be capable of it.

Subversion allows it, but it doesn't remember merges at all, so really
it's putting all the responsibility on the user.  i.e., you can
construct diffs between revisions, apply them, and then commit.
That's how I interpret what "svn merge" does, anyway.  svk seems to do
a bit more.  Still not what you're asking for, though---I guess nobody
supports it yet because it's tricky to specify cleanly.

[...]