Hi Erik,
I'd still consider the merge to be behaving as expected. This hinges on
Subversion treating the empty line as a valid block.
Consider if <emptyline> is replaced with further lines of code. And
maybe throw some in above the first line too. Would you still consider
the merge to be wrong, looking at the lines in your example? If the
original file (A) committed had been:
load records_2004
read path_to_tax_records
if some_global_var:
print "going to delete all files"
if audit_in_progress
print "record not found"
and the same updates as below were followed, what would you expect (B)'s
merged file to be, if not:
load records_2004
read path_to_tax_records
rm -rf /var/database
if audit_in_progress
print "record not found"
On the resulting (potentially severe!) bug introduced - an automatic
merge can never understand the program logic of the files it merges.
Consider the standard example of "Why humans should read the results of
a merge"
Buggy Code:
~~~~~~~~~~~
if a > b then
max = b
Albus fixes this in his development branch, tests it and all's well.
Bart fixes this in trunk, but differently, tests it and all's well.
Albus Bart
~~~~~~~~~~ ~~~~~~~~~~
if b > a then if a > b then
max = b max = a
Merge the changes together, and the same bug re-appears.
Merged (Buggy again)
~~~~~~~~~~~~~~
if b > a then
max = a
A merge will operate based on lines, with no understanding of what those
lines do.
I don't know about the odd behaviour of "svn update" when using diff3.
Seems a little wrong to list "G" yet also create .mine etc; but as I
work on Win32 machines I can't easily try that one.
Cheers,
Rob Swarbrick
-----Original Message-----
From: Erik Enge [mailto:eenge@prium.net]
Sent: 14 September 2005 20:56
To: Robert Swarbrick
Cc: users@subversion.tigris.org
Subject: RE: Odd behaviour when merging.
Quoting Robert Swarbrick <robert.swarbrick@asg.com>:
> This is based on my knowledge of using Subversion, not an
> understanding
> of the source code.
Thanks for your reply. I can see your point and I appreciate your
taking time and laying it out so nicely though I would like to
illustrate my side of it using the same example, just different
text on the lines and prehaps get your comments on this version.
(Pseudocode ahead.)
(A) commits the file:
if some_global_var:
print "going to delete all files"
<emptyline>
(B) obtains this file in an update, and doesn't like it at all:
<emptyfile>
(A) realizes he forgot to add the rm -rf and does so by commit the
following file:
if some_global_var:
print "going to delete all files"
rm -rf /var/database/
<emptyline>
(B) now performs the update and subversion says "G" which he
takes to mean that there were changes but it successfully merged.
He takes a look at the file:
rm -rf /var/database/
<emptyfile>
The conditional rm -rf has turned into an unconditional one. Is it
your view that it still does the right thing? CVS gives a conflict and
so does svn using --diff3-cmd=/usr/bin/diff3 (even though Subversion
says G it actually puts the .mine, .rev1 and .rev2 files in the
directory - which has correctly identified the conflict, IMHO,
but that's a separate problem, I suppose).
Thoughts?
Thanks,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 15 10:12:18 2005