[cvsnt] cvs rename bugs

[Olaf Groeger]

Not offense meant (just my thoughts), but i disagree with yours and some
others opinion:
1) There is not difference between move and rename. The location of a file
is only one attribute of it. Though it is the identifying attribute, it
remains an attribute. Whether i add/remove some directory separators or
change only some characters, makes not differences. Treat the file name as
one identifier. Which part of the identifier i change is a detail, but what
remains is that i changed the identifier. This comes out more clearly if
you imagine to move the complete cvs repository to a database, which Tony
is going to do, IFAIK.
2) The use of two commands would be tricky, in my opinion. Consider this
example:
I have the following files in my sandbox
File1.txt
dir1/File1.txt
dir1/File2.txt
Now i want to change dir1/File1.txt to File2.txt. Using two different
commands means i must use them one after another, but i can't rename
dir1/File1.txt to dir1/File2.txt, because it already exists, and i can't
move it to File1.txt, because it exists, too. So regardless of which
operation i try, i can't perform it.
3) Makes renaming/moving sense in CVS?
One feature of CVS is that it handles files completly independant of each
other. I don't know whether this was by intent or a "spin-up". You can add,
commit, remove, even update each file in a directory independant from each
others. But the renaming feature creates magical bindings between files.
Example:
I have a file file1.txt with some revisions. Now i rename the file to
file2.txt. Some days later i add another file1.txt. This is from the point
of view of a user ok, because currently such a file doesn't exist. But now
it is not possible to have both the old revision of file2.txt (formerly     
file1.txt) and the current versions of file1.txt in the directory at the
same time, meaning  that some revisions of different files are coupled at
each other. Yes, i know that the two file1.txt never existed at the same
time "in the time continuum", but this is exactly the freedom CVS offers
me. I'm allowed to have file revisions of differenct files coexistant in my
sandbox even when they are from different age. 

I want to make it clear, that i agree with all of you, that renaming is a
must-have of a modern SCM, and i would need it, too. I'm a java programmer
and easy refactoring is one of the highlights of the IDEs. But i can't see
how a SCM that manages files and their revisions inpendant of each other
can handle this in a proper way. So if we can't handle this in a proper
way, should we really add commands for it and pretend that this is really
working? In my opinion the add/remove commands are sufficient. A clever CVS
GUI can combine these commands easy to a rename/move action. The thing that
we are missing is the link between the old (and now removed) file and the
new file! I suggest to extend the files in the cvs repository about meta
tags which can hold such information as "I'm file1.txt, but before revision
1.35 i was dir1/file2.txt" and 'I was dir1/file2.txt until revision 1.4,
then i became file1.txt" and extend the add and remove command on setting
these meta tags. Than a CVS GUI can add the new file together with setting
the link information to the old file, and remove the old file setting the
link information to the new file. The log command can make use of this
information, too, and deliver the information from the new file and then
continue with the information from the old file starting from the deletion
point. From my point of view this would do the job.

Olaf