Cherrypick without merge needed

[JetMark]

There is a lot of discussing amongst the new SCM systems of cherry picking.
Most seem to miss the point in my book.

They define cherry picking as the ability to merge an arbitrary change into
an arbitrary branch. The problem with this approach is that when the changes
are merged in in an order that is not the same as the commit change order it
is possible that there may be merge conflicts or indeed no conflicts but an
incorrect merge. (The functionality is not what the developer expected. )
Worse than this, if several changes (commits I mean) actually occur for a
single feature, there may be no correct order that results in each file
having changes applied in the correct order. This means that the results of
such a merge always need to be checked. 

For some time in CVS I have use a process where we would record (externally)
particular checkins with a bug number and regard this as a changeset. The
cherrypicking operation is the operation of moving the build tag forward in
the file set associated with the bugset. The rule is that it is never
permissible to move a tag forward in a file if this would result in the
inclusion of any non-cherry picked material. The point about this is that
cherrypicking NEVER results in a conflict or indeed in anything that has not
been eyballed by a developer before a checkin. It cant, its not a merge! If
it works it never goes wrong. It is possible that a combination of bugs
cannot be cherrypicked, but this can be rapidly identified before the pick
is done. So either you have to add more bugs to the list , remove some or
wait. But there is never any merging.

So what do we need to do this in Bazaar? Perfect would be the ability to
guarantee when merging an arbitarary list of changes that no file has any
other changes included, or the request fails. Such a merge can be done by a
copy operation. If 3 bugs use 3 seperate files then any order is (clearly)
fine, and any combination or all 3 at once should be fine. if 1 file has
material common to two of the bugs then either those two bugs must be done
at once or they must be done one at a time IN THE ORDER THAT THE REVISIONS
WERE MADE IN. In other words what Id like is a kind of conditional merge
function - can you do this while only applying changesets to the actual
versions they were generated from? 

I said this never goes wrong. I lied slightly. just because the modified
versions of 2 files is fine, and the unmodified versions are fine, does not
mean that unmodified will always work with modified. But, if its different
bugs, its likely to be the case in the real world. And if its the same bug
then the developer or team responsible should have modified both files
before the bug was cherrypicked, shouldnt they , so again it should not
happen that the system is left in an inconsistent state.

Other possible Bazaar implementations could be if we had the ability to
generate a special manifest file and generate this as a branch but I do not
know how to do this or if it is possible.

Another route to a Bazaar implementation would be if I could move a tag on a
single file or list of files, this would also allow me to very simply
achieve what I am trying to do here, I could modify an existing tag to newly
include changed files without checking in any new material. Kind of mixed
revisions. 

This is intended to be a wishlist feature, but I submitted as a bug ,
#242661 probably the wrong thing to do in fact. 

So how about it? Has anyone else got the need for this? Is there something
in the API or the command set that would help me do this that I missed? I
find it hard to believe that other people do not do this? Of course they
do!! At present this is a major 'blocker' for us.
-- 
View this message in context: http://www.nabble.com/Cherrypick-without-merge-needed-tp18212682p18212682.html
Sent from the Bazaar - General Discussion mailing list archive at Nabble.com.