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

Re: Automated Merge Conflict Resolution before svn 1.5?

From: Hari Kodungallur <hkodungallur_at_gmail.com>
Date: Wed, 16 Jan 2008 12:36:09 -0800

On Jan 16, 2008 7:39 AM, M@ Hunter <technologyrocks_at_gmail.com> wrote:

> I've spent a fair deal of time looking for an answer to this, and I'm left
> with the feeling that I may be out of luck until version 1.5 is out. I'm
> hoping, however, that someone has a solution I can use now...
> Basically, we have a setup like this:
> /project/trunk
> /project/branches/[time_stamp] <---many of these
> /project/branches/current
> We have a set of automated scripts we wrote that create these time-stamped
> branches. These branches are used for pre-production. Our staging and
> production servers are running the code contained in current - and that code
> is NEVER locally modified. When we're satisfied that the code in a
> timestamped branch is ready for production, we run an automated promote
> script - and it runs a merge of the time-stamped branch into 'current'. The
> staging machine is then automatically updated so that it has the latest
> files from 'current', and then an automated build is run.
> This was working great until the other day when we saw an unexpected
> conflict merging the time-stamp branch into 'current'. Because we're never
> modifying 'current' directly, we mistakenly assumed there would never be
> conflicts. We obviously mis-understood the difference between update and
> merge in this respect.
> I've seen that in svn 1.5, there will be a way to resolve conflicts by
> saying '(m)ine or (t)heirs' - which seems perfect, especially if we can
> automatically alway choose 'theirs'. This would completely fix my current
> problem... but, before then - is there anyway to do this with 1.4?

During conflicts, svn will create the following files:

In your case, you want to take the NEWREV (which is "their" change). You
will have to do some scripting to find out that revision number. In your
case, I think it will always be the higher number.

So, just do
  cp file.rNEWREV file
  svn resolved file
  svn commit

This will be the equivalent of taking 'their' change. Not straightforward,
but scriptable.

Received on 2008-01-16 21:36:32 CET

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.