On Tue, Mar 12, 2019 at 04:04:56PM +0100, Stefan Sperling wrote:
> On Tue, Mar 12, 2019 at 02:43:32PM +0000, Jonathan Guy wrote:
> > Hi all
> > Not sure if this is a bug or expected behaviour.
> >
> > Using Subversion 1.11.1
> >
> > Two people with separate checkouts working on the same file.
> > Person A edits a line and the renames the file and commits.
> > Person B edits the same line in the same file and then does an update.
> > > The conflict resolver first flags the tree conflict which is resolved with a move and merge.
> > The subsequent merge then produces the second conflict.
> >
> > Here’s were the behaviour is not what I expected. If I select “tf” so accepting all incoming changes I end up with a file that is resolved but is showing as modified. I check the contents and it contains my changes.
> >
> > Conversely if I resolve using “mf” so rejecting incoming changes I end up with a file that is resolved but is showing as normal and is identical to the head version and I have lost all my changes.
> >
> > I’m pretty sure this not the intended behaviour but I could be wrong.
> >
> > Regards
> > Jonathan
> >
> >
>
> Hi Jonathan,
>
> Yes, this is a bug. The text merge performed by the resolver has the
> '.new' and '.working' sides swapped. It works correctly during 'svn merge'
> but not during 'svn update'.
>
> I will try to fix this.
Fixed in https://svn.apache.org/r1855419
I'll nominate this fix for backport to 1.10/1.11/1.12 now.
Received on 2019-03-13 14:17:16 CET