Cherrypick without merge needed

[Tom Widmer]

JetMark wrote:
> 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.

I think the latter is no more common than the example you give below 
about one modified files requiring another to be modified (despite the 
modifications relating to different bugs). The former only occurs when 
the changes affect the same parts of the file.

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

Ideally by compiling (in an applicable language), and running a unit 
test suite.

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

Well, it's not a file merge, but it is a tree merge (you're combining 
different states of bits of the tree into a new state).

But what if one of the bug fixes involves renaming a file?

  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? 

Hmm, CVS has per-file versioning (in common with e.g. Visual SourceSafe, 
the tool I've used most in the past), and as such allows you to play per 
file tricks. Bazaar (and others, such as Subversion, etc.) version the 
whole tree (which has obvious benefits, though makes some tricks 
'trickier').

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

This is kind of equivalent to the 'silent' merge conflict case in Bazaar.

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

I think most people are happy to cherry pick changes and resolve 
conflicts manually (often using visual merge tools). However, an 
extension that could query what changesets can be cherry-picked without 
requiring anything but per-file fast forwards, and that could query what 
other changesets you need in order to cherry pick one of your choice 
without any per-file auto-resolutions, combined with the ability to have 
a per-file fast forward style merge (producing conflicts otherwise), 
would obviously be useful to you, and perhaps to anyone else who manages 
some of their stable branches in this way.

Tom