Automated Merge Conflict Resolution before svn 1.5?

["M@ Hunter" <te...@gmail.com>]

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?

Thanks!
M@

Re: Automated Merge Conflict Resolution before svn 1.5?

["M@ Hunter" <te...@gmail.com>]

Hi Hari,

Thanks - that's actually the solution I just started coding ;)  Was kinda
hoping I'd find a cleaner svn way to do it, but at least it'll fix things
for now.  Thanks for the reply - I appreciate it :)

M@

> During conflicts, svn will create the following files:
>   file.mine
>   file.rOLDREV
>   file.rNEWREV
>
> 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.
>
> Thanks,
> -Hari
>




Thanks - that's actually the solution I just started coding ;)  Was kinda
hoping I'd find a cleaner svn way to do it, but at least it'll fix things
for now.  Thanks for the reply - I appreciate it :)

M@

Re: Automated Merge Conflict Resolution before svn 1.5?

[Hari Kodungallur <hk...@gmail.com>]

On Jan 16, 2008 7:39 AM, M@ Hunter <te...@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:
  file.mine
  file.rOLDREV
  file.rNEWREV

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.

Thanks,
-Hari

Re: Automated Merge Conflict Resolution before svn 1.5?

[Michael J Gruber <mi...@fastmail.fm>]

M@ Hunter venit, vidit, dixit 16.01.2008 16:39:
> 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...
...
> 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?
> 
> Thanks! M@

You can mimic this behaviour by specifying an alternative merge
programme. Doing something like

svn merge --diff3-cmd=svnmergetheirs ...

where svnmergetheirs is a shell script doing nothing but

cat ${11}

should suffice, see
http://svnbook.red-bean.com/en/1.4/svn.advanced.externaldifftools.html
for other arguments you may use.

Cheers,
Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org