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

Re: Conflict when merge tries to add

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-07-14 03:03:02 CEST

On 7/13/06, Reedick, Andrew <Andrew.Reedick@bellsouth.com> wrote:
> > -----Original Message-----
> > From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of
> >
> >
> > As was recently pointed out by Andrew Reedick on the users list,
> > currently, if 'svn merge' tries to add a file and that results in a
> > conflict (say there was a different file with the same name added on
> > both a branch and the trunk, and then you try and merge the branch
> > into the trunk) we print out an A, not a C. There's a trivial change
> > to fix that, but it causes some test failures, so I figured I should
> > bring it up here to make sure that we really should print C. I mean
> > it makes sense to me, but clearly someone at some point decided that
> > printing A was correct, otherwise they wouldn't have wrote the tests
> > that confirmed it...
> >
> > Just an oversight?
> >
> > Here's the diff to fix the problem (minus fixes to merge tests, those
> > are trivial enough though):
>
>
> Are you always printing 'C', or
> only printing 'C' if the file contents really are in conflict?
>
> I'm pretty sure it's the latter, but I just want to be sure.
> > + if (n->content_state == svn_wc_notify_state_conflicted)
>

Yeah, I'm only printing it if the contents are actually in conflict.
I also wonder if I should be looking for property conflicts...

> On a related note, in the reverse situation, if the file contents are
> identical,
> -svn merge prints 'A', but
> -svn status prints nothing, because the contents are
> unchanged...
>
> I'm going to go out on a limb and say that should be fixed also.

Possibly... Will have to look at how hard it is to fix that.

> However, by doing either one, we lose the ability to detect ancestry
> changes during a merge. Seach each file object/evil_twin has a
> different ancestry and history, Someone(tm) may want to choose which
> object to keep. Without the 'A' from the 'svn merge' output, they lose
> the ability to detect these cases. Personally, I'm happy that svn
> auto-magically resolves evil twins in a common sense way (after 7 years
> of ClearCase and trying to explain evil twins to users), but there's a
> part of me that wonders about potential ancestry/merge issues down the
> road.

Well, people looking to do that can always use the language bindings
and look at the status codes directly...

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 14 03:03:35 2006

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

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