> -----Original Message----- > From: Gavin Baumanis [mailto:gbauma...@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.)