Ben Collins-Sussman wrote:
>Lele Gaifax <lele@seldati.it> writes:
>
>
>
>>Hi all,
>>
>>I'm trying to understand the mechanism of merge when coupled with
>>renames and deletes. It seems that the merge command completely
>>ignores the rename operation, giving unexpected results.
>>
>>To test the case, I supposed to have to track an external sw, the
>>"third-party" model:
>>
>>/vendor
>> /current
>> /product-1.0
>> /product-1.1
>>/mine
>> /current
>> /enh-product-1.0
>> /enh-product-1.1
>>
>>PoW A: for whatever reason, I decided to rename the source "main.c"
>> to "product-main.c".
>>
>>Where "product-1.2" gets released, I do the merge: argh! they modified
>>"main.c", and I obtain:
>>$ svn merge svn://.../vendor/product-1.1 svn://.../vendor/product-1.2
>>svn: Can't find an entry
>>svn: svn_wc_merge: `main.c' not under revision control
>>
>>
>
>This isn't unexpected, this is correct.
>
>You're asking 'svn merge' to compare two trees and then apply those
>differences to your working copy. So one of the differences is that
>some text changed in 'main.c'... but your working copy *has* no file
>by that name. So just like when you apply a patch, that 'hunk' fails.
>
>There's no good solution to this problem: the diff just doesn't apply
>cleanly. There's no way Subversion can "guess" that some file in your
>directory used to be named 'main.c'... at least not without some huge
>brute-force search heuristic!
>
Oops, careful there. Subversion doesn't need any brute-force search
heureistic, it has the file's history. However, read on...
>>PoW B: this time, the *vendor* renamed that file, while my version
>> still has "main.c", a customized version of 1.1
>>
>>At merge time, *my* changes to main.c aren't honored:
>>$ svn merge svn://.../vendor/product-1.1 svn://.../vendor/product-1.2
>>A product-main.c
>>D main.c
>>
>>At this time, my changes are silently gone.
>>
>>
>
>Sure, once again, it's applying a patch to your working copy. The
>patch is to rename main.c->product-main.c, because that's exactly the
>difference between the two vendor trees. No surprises here at all.
>
>What were you expecting? :-)
>
>Perhaps you're confused about how svn does renames. Remember that a
>rename is an 'svn rm' + 'svn cp', and an 'svn cp' is just an 'svn add'
>which remembers copy-history. So that's why you're seeing the 'A'
>and 'D' in your merge there. It's a rename.
>
This example is exactly why I keep saying that we should make "svn mv"
an atomic operation that *does not* generate a new node in the
filesystem. Then moves would become pure directory changes, and "svn
merge" has to resolve those before merging the files themselves, like
Philip said -- and so it would know before even starting the file merge
that it found a rename.
I think that the way things stand now, "svn merge" will break horribly
on a driectory rename; it'll replace the whole subtree instead of
merging it.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 17 23:53:32 2003