RE: Merging change sets for a production release,

> -----Original Message-----
> From: Gavin Baumanis [mailto:gbaumanis_at_cogstate.com]
> Sent: Monday, June 03, 2013 2:27 PM
> To: Andrew Reedick; users_at_subversion.apache.org
> Subject: RE: Merging change sets for a production release,
>
> Hi Andrew,
> Thanks for your response.
>
> I do everything but for the chaining of the revisions to merge in the
> same command.
> I tried it once (granted a long time ago) and it caused such an issue
> for me that after about 6 hours of swearing, I finally gave up and
> reverted the changes and did the merges one by one.
> At the time one by one allowed for individual merge conflicts - which
> made life a little easier.
>
> As for the other ideas, we do already only merge changes from trunk
> that are complete and have been given the appropriate release
> milestone.
> Our release process is already issue-based.
>
> Perhaps simply chaining the merge revisions is the answer?
>

Yes, I would try the 'svn merge -c ...' "changed" merge again.

Assuming you're using SVN 1.7, "chained" merges should be much easier. It is still an iterative process, in that if a merge conflict is encountered, svn will prompt you for what to do, then you fix the code, resolve the conflict, and re-run the merge command to pick up where it left off. You will probably want to use 'svn merge --accept postpone ...' to avoid the prompting. It's normally a good idea to save off your merge command so you can add it to the commit comment (or in case anything happens to your command line's history buffer.)
Received on 2013-06-03 22:09:43 CEST