Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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