[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Merging change sets for a production release,

From: Gavin Baumanis <gbaumanis_at_cogstate.com>
Date: Wed, 5 Jun 2013 06:50:33 +0000

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_at_cbeyond.net]
> Sent: Tuesday, 4 June 2013 06:08
> To: Gavin Baumanis; users_at_subversion.apache.org
> Subject: 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-05 08:55:35 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.