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

RE: svn merge lies?

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-07-11 22:09:52 CEST

> > The 'svn merge' output says "A" or "U", but 'svn status'
> lists them as
> > 'C' and they do have merge conflict files (left, right,
> working.) This
> > affected both text and binary files. In my case, the text
> output from
> > 'svn merge' listed 61 conflicts, but actually generated 254
> conflicts.
> > Which was a rude shock since we were working off of the 61 conflict
> > list.

> This has been "fixed" (i.e. we now report C, not A, which isn't ideal,
> you'd like to have both bits of info, but still, better than nothing)
> and will be in the first 1.4.x release.

Thanks for the fast response.

So what is going on here? Is it a case of 'evil twins', aka the
'deleted and added instead of copied' issue? Along the lines of:

        foo.java(1) and foo.java(2) have the same name but are different
objects with different history, ancestry, etc. on different branches.
Evil twins are normally created when you do an 'svn add' to add foo.java
to two different branches (creating two unique objects,) instead of an
'svn add' on branch one, and then an 'svn copy' to branch two (which
creates two references to a single unique object.)

        So two merges are done. One to merge the objects (hence the A
or U reported by 'svn merge',) and the 2nd to diff/merge the two
objects' files' contents. So it's really (A or U) plus C?

More importantly, I have a vague, queasy feeling that since the ancestry
is different for each foo.java object, future merges may have subtle


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 11 22:11:19 2006

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.