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

RE: Odd behaviour when merging.

From: Robert Swarbrick <robert.swarbrick_at_asg.com>
Date: 2005-09-14 08:42:36 CEST

Hi Erik

This is based on my knowledge of using Subversion, not an understanding
of the source code.

I think you may not be considering the file as "blocks that change".
Stepping out of the (byte-swapped!) hex dumps, here's the files
more-or-less in English:

(A) commits the file:

(B) obtains this file in an update, and doesn't like it at all, so edits
it to have just an empty line. No matter how it's done, this is
identical to deleting a two-line block above the original last line.
            line0 deleted by (B)
            line1 deleted by (B)

In the meantime, (A) adds in another line, just after the original
two-line block and before the block consisting only of <emptyline>
            line2 added by (A)

When (B) now performs an update, Subversion sees that
-> (A) has added in 'line2'
-> (B) has removed 'line0 line1' in local edits

So the resulting merged file leaves out the two lines (B) deleted, and
includes the additional line committed by (A).
            line0 deleted by (B) } Block1
            line1 deleted by (B) }
            line2 added by (A) } Block2
            <emptyline> unchanged } Block3

This is what I would expect a merge to do. The resulting file has all
the changes made by both users. Any merge or diff program has to look
for blocks that change, and can't run on just line numbers; as far as
Subversion is concerned the <emptyline> never changed.

That conflict you mention:
If (B) creates a completely empty file, this causes a conflict because
Subversion cannot find any marker to know where to insert the line
containing text 'line2', as added by (A). So it flags this for human

Hope this helps,
Rob Swarbrick

-----Original Message-----
From: Erik Enge [mailto:eenge@prium.net]
Sent: 14 September 2005 00:06
To: users@subversion.tigris.org
Subject: Odd behaviour when merging.

The company I work for is in the process of validating that
Subversion will work as a replacement for CVS, we have run
into a somewhat odd problem which I would like to show you and
perhaps get some insight into either what I'm doing wrong or
what might be going on. Please bear with me during the following
exercise (some Subversion output has been removed but I left
the A/U/Gs etc to illustrate exactly what Subversion responds
with each time I interact with it, more information can be
provided if this is not sufficient):

User A adds a file called ``test'' to the repository:

usera$ echo -en "line0\nline1\n\n" > test
usera$ od -h test
0000000 696c 656e 0a30 696c 656e 0a31 000a
usera$ svn add test
A test
usera$ svn commit test -m "adding test file with three lines;
last line empty"

User B checks out the file just added by user A:

userb$ svn up
A test

User B decides that this is garbage and replaces the file with
one empty line (note that if you replace it with a completely
empty file - eg echo -n "" > test - you'll get a conflict later
userb$ echo -en "\n" > test
userb$ od -h test
0000000 000a

In the mean time, User A changes line 3:

usera$ echo -en "line0\nline1\nline2\n\n" > test
usera$ od -h test
0000000 696c 656e 0a30 696c 656e 0a31 696c 656e
0000020 0a32 000a
usera$ svn commit test -m "oh, forgot line2, just added it,
pushed the newline down one"

Ok, here's my thinking at this point: When user B now updates his
repository he should get a conflict for that file. He has changed
line 3 (he removed it) and so did user A (he changed the contents of
it), however it merges fine:

userb$ svn up
G test

and now contains:

userb$ cat test

userb$ od -h test
0000000 696c 656e 0a32 000a

Am I confused or is there something weird going on? I'm sorry for the
contrived example however this occurred for us in our testing in real
world code; the test file and its contents as above is the result of
my boiling down our real world example. There might still be
possibilities for making the example even shorter but I think this is
sufficiently short.

I was wondering if this were related to


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 14 08:44:42 2005

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.