On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview)
<steve.varnau_at_hp.com> wrote:
> Hi,
>
> I could not find this issue in the issue tracker. We’re trying to keep the
> svn:mergeinfo properties on top-level directories, but I found a few text
> files in our repository that have the property. When a merge is done that
> should be just a branch synch-up merge, the files are marked as conflicted,
> and the entire file is one big conflict, as if it is an EOL character
> problem.
>
> All of the files that are marked as conflicted have in common two
> properties. They have an svn:mergeinfo, and they have svn:eol-style =
> native. Both branches have the same svn:eol-style value. The text file that
> did not have an svn:eol-style property merged just fine.
>
> When the files are edited (Tortoise “Edit conflicts”) it shows no conflicts
> -- merge with no problem. Looking at the files, there are no EOL character
> differences. Both sides (left & right files, and both sides of the working
> conflict file) have CRLF.
>
> The files also merge fine on Linux.
> The files also merge fine if given the option to ignore end-of-line.
> The problem occurs whether the merge is done via Tortoise or command-line on
> Windows.
> Svn version 1.6.15.
>
> Somehow it seems to be giving up merging these files only when there is a
> svn:mergeinfo property.
>
> I will try to just remove the mergeinfo property on all the files, but
> wondered if this is a general bug.
I think this is the following issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=3657 - dav update
report handler in skelta mode can cause spurious conflicts
(this issue previously had another summary: "phantom svn:eol-style
changes cause spurious merge text conflicts", which may sound more
recognizable, but this was later changed when they found out more
about the issue).
It describes more or less the same situation: a merge with some prop
change which happens together with a text change, and the entire file
is marked as conflicted. I've run into this situation myself a couple
of times (I then just resolved the conflict by choosing "theirs-full"
or something, after having assured myself that this was indeed the
issue).
It's fixed in svn trunk, so scheduled to be in the upcoming 1.7
release. AFAIK, it's not currently nominated for backport to 1.6.
Cheers,
--
Johan
Received on 2011-02-24 10:48:15 CET