subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Baumanis <gbauma...@cogstate.com>
Subject RE: Merging change sets for a production release,
Date Wed, 05 Jun 2013 06:50:33 GMT
Hi again - 
I have a follow up question, please.

I had an helpdesk issue with 18 changesets attributed to it.
It took a while to resolve all the issues - but I finally got there.

I did a "diff" on one of the files and I noticed that in the revision that there was a conflict
for that file - there was no mergeinfo recorded for that revision.
Do I need to do a --record-only "post" merge when there is a conflict?

As always - thanks,

 - Gavin.


> -----Original Message-----
> From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net]
> Sent: Tuesday, 4 June 2013 06:08
> To: Gavin Baumanis; users@subversion.apache.org
> Subject: RE: Merging change sets for a production release,
> 
> 
> 
> > -----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