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 ...).
This happened with the following, not so unlikely, scenario:
1) During refactoring, user 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.
Relevant mailthread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2362659
Major 