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:
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
Received on 2008-01-16 21:36:32 CET