[Bug?] svn moving A to B and B to A becomes replace

We have experienced some strange, and IMHO undesired, behavior. I've searched the SVN bug database and mailinglists, but haven't found anything exactly the same. Is this a bug?

Short description:
Moving a file in a WC (svn mv) to another filename, then moving it back to the original filename, generates a "replace" (i.e. a delete and add of another file with the same name, thereby breaking the history).

Reproduction script (suppose test.txt is a versioned file in my working copy):
========
$ svn mv test.txt test.txt2
A test.txt2
D test.txt

$ svn status -N
A + test.txt2
D test.txt

$ svn mv test.txt2 test.txt
A test.txt
D test.txt2

$ svn status -N
R test.txt
========

This is quite destructive, as svn thinks the file was replaced by a new file (with no historical link to the original one). After committing, the file loses the old line of history (of course, I know it's not totally lost, because you can still get to it with peg revisions, but still ...).

A colleague of mine ran into this with the following, not so unlikely, scenario:
1) During refactoring, he decides to rename a file (all within his IDE, to have adequate refactoring of all references to the file).
2) He does some further changes, including changing the content of the renamed file.
3) He changes his mind about the rename, and renames it back to the original name.
4) He commits
Result: file is "replaced", history is "lost"

Note that, because of step 2), he couldn't just revert the name change. If he would have committed after 1) or even after 2), and then renamed it back, there would have been no problem.

Regards,
Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2362659

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-17 02:13:47 CEST