>>>>> "Ryan" == Ryan Schmidt <subversion-2008c_at_ryandesign.com> writes:
Ryan> On Sep 3, 2008, at 8:12 PM, Paul Koning wrote:
>> I have a merge problem with SVN 1.3 or thereabouts; I wonder if
>> this is an old bug.
>>
>> Scenario goes like this:
>>
>> rev 10: branch trunk to branches/a rev 20: make some changes to
>> trunk/file1 rev 25: make some changes to branches/a/file1 rev 30:
>> rename branches/a/files1 to branches/a/file2
>>
>> Now merge revs 10:30 from branches/a to trunk.
>>
>> Result: trunk now has "file2" with the changes that were in rev 25
>> on the branch. "file1" is gone, because the rename amounts to a
>> delete of the old name.
>>
>> The problem: the change in rev 20 to trunk/file1 is silently lost.
>> It should be a conflict.
>>
>> Is this fixed in a more recent release? If not, it's a major bug
>> that needs fixing...
Ryan> As far as I know, this unfortunate behavior still occurs with
Ryan> Subversion 1.5.2, though I did not test it.
Ryan> Possibly this issue:
Ryan> http://subversion.tigris.org/issues/show_bug.cgi?id=2685
Ryan> And this:
Ryan> http://subversion.tigris.org/issues/show_bug.cgi?id=3210
It sure looks like the same issue.
I think the underlying problem is how Subversion handles renames.
It is perfectly fine to model a rename as an add plus a delete --
except for merges. Then it matters. The question is: if the history
shows an add/delete pair, what did the user have in mind?
1. A rename, or
2. A copy of an existing file, followed (possibly later) by a delete
If I have file "f1" and make a copy "f2", then subsequent changes to
"f1" should't affect f2. If later I delete f1, that means I no longer
want it.
On the other hand, if I rename "f1" to "f2" then I have just one
container, though its name changed. Any changes to what's inside that
container I want to see, and merge should pick them up.
So this means that in the scenario I originally described, the changes
on trunk in rev 20 should be carried forward (merged, as any other
contents change) when I do the merge from branch to trunk.
Now the problem becomes: how should Subversion tell the difference
between a "copy and then at some point a delete" (where I do NOT want
rev 20) vs. a rename (where I do).
One answer is a heuristic: if the copy and the delete are in the same
revision, then it's a rename. If not, then it's not a rename. But
that makes trouble if someone checks in the result of the rename (in a
working directory) with two checkins, one for the source subtree, one
for the destination subtree. Yes, that's bad practice, but it is
technically allowed.
The other possible answer is to recognize that "add plus delete" as an
encoding of "rename" is the underlying problem. So don't use it --
create a new type of history entry which is "rename". Then "add plus
delete" means exactly that, the user did those two separate steps.
Merging of such a change would be as it is today. On the other hand,
a rename ("svn mv") would be a "rename" history entry instead, and
that is merged the way I expected to see things (i.e., rev 20 is
carried forward, in the above example).
A benefit of a "rename" type history entry is that it would avoid the
problem of checkin in only half the rename. The action would be
defined to happen when you check in the source subtree, or the
destination subtree (or either?) -- but whichever checkin records it
would record the whole action, atomically.
I'm not sure which solution is best. I'm not comfortable with the
heuristic, but I don't know much about Subversion internals so I can't
judge whether "add a 'rename' type entry" is really hard, or not all
that hard -- or whether the heuristic is hard, for that matter.
Any comments? I would be willing to take a stab at this with some
help and some feedback about the right direction to take...
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-04 17:05:31 CEST