Vladimir Prus wrote:
>
> I'm not sure if this behaviour is right or wrong, however:
> Say I have directory "src" with file "main.cpp" in it.
> I do:
>
> svn cp src src2
> cd src2
> svn mv main.cpp hello.cpp
> edit hello.cpp
> svn ci -m ""
> cd ../src
> edit main.cpp
> svn merge -rX-1:X ../src2
>
> (Here X is the revision created by commit).
>
> This fails: svn tries to delete "main.cpp", which is locally modified in
> src. I would expect that svn notice that main.cpp was renamed in branch,
> and merge local mods of main.cpp with hello.cpp from branch, silently
> deleting main.cpp. Is this a reasonable expectation?
It's a reasonable expectation, if the svn treated renames as atomic
operations, instead of "delete + copy". We had a big discussion about
this a couple of weeks ago, see issue #898.
For the time being, the server compares the two versions of src2, and
simply notices that main.cpp was deleted between the two trees (not
"renamed") -- so it will try to 1) delete your main.cpp in src, and 2)
copy a new file into src, whose ancestor is main.cpp. It's working
correctly right now, given our design. If/when we move to making
renames truly atomic operations, then the behavior you describe above
should happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 25 14:40:26 2002