On Mon, Mar 21, 2016 at 3:23 PM, Bob Berger <rsberger1_at_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
Received on 2016-03-22 10:08:13 CET