subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Reedick <Andrew.Reed...@cbeyond.net>
Subject RE: Merging change sets for a production release,
Date Mon, 03 Jun 2013 20:08:20 GMT


> -----Original Message-----
> From: Gavin Baumanis [mailto:gbaumanis@cogstate.com]
> Sent: Monday, June 03, 2013 2:27 PM
> To: Andrew Reedick; users@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.)



Mime
View raw message