On Mon, Mar 21, 2016 at 3:23 PM, Bob Berger <rsberg...@hotmail.com> wrote: > Thanks for your reply Stefan. It's very much appreciated. > > Before Subversion 1.8 made the reintegrate merge automatic, I was doing > merges without the reintegrate option, which were, I suppose, inappropriate > "complete merges". They were > generally effective, but sometimes produced errors and strange conflicts. > With Subversion 1.8 or higher, I am forced to cherry-pick, which may > sometimes produce poor results if I pick the > wrong cherries. I had regarded cherry-picking as error-prone and something to > be avoided, but it's good to know that it's used successfully elsewhere.
We use cherry-picking in our organisation too, for backporting specific fixes from trunk to release branches. I believe that's the most natural way to work with release branches. I don't regard it as error-prone at all, but you have to organise a bit of process around it. For each release (branch) we have: - A wiki page, where developers list fixes to be backported (i.e. to be merged to the release branch): revision number, log message, link to a review, and commentary why it needs to be backported. - A build master (which is a rotating job, everyone takes turns doing it): does the merging and building on a dedicated build machine. - A little script which is fed (by the build master) with the revision numbers to be cherry-picked. It first shows the commit messages and affected files (simply 'svn log -v -rX') so the user can verify, and after confirmation performs the cherry-pick merge; and after another confirmation commit to the release branch. -- Johan
