You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Varnau, Steve (Neoview)" <st...@hp.com> on 2011/02/24 00:56:03 UTC
Merge Conflict on Windows with eol-style & mergeinfo properties
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.
-Steve
RE: Merge Conflict on Windows with eol-style & mergeinfo properties
Posted by "Varnau, Steve (Neoview)" <st...@hp.com>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: Thursday, February 24, 2011 1:47 AM
> To: Varnau, Steve (Neoview)
> Cc: users@subversion.apache.org
> Subject: Re: Merge Conflict on Windows with eol-style & mergeinfo
> properties
>
> On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview)
> <st...@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
Yes, that does appear to be the one! Thank you.
-Steve
Re: Merge Conflict on Windows with eol-style & mergeinfo properties
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview)
<st...@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