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.
Olaf Groeger wrote: > Not offense meant (just my thoughts), but i disagree with yours and some > others opinion: > 1) There is not difference between move and rename. One moves, the other renames. Seems different to me... just because under Unix/linux one command does both, sigh, does not make them the same. > The location of a file > is only one attribute of it. Though it is the identifying attribute, it > remains an attribute. A pretty import one, since its how the file is referenced. > Whether i add/remove some directory separators or > change only some characters, makes not differences. Yes it does, you are moving it around the [module] hierarchy. > 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. How the backend stores its data is irrelevant... cvs is a file-oriented revision management system... it works client-side with files in directories. > 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. remove; move/rename or move/rename (if move automagically does a remove if its going to overwrite an existing file) > 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". By accident. CVS evolved from (or rather was hacked onto) RCS which was very file-oriented. > 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. There are no magical bindings, per se. > 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. You should checkout based on a tag or a date... explicitly checking out by [internal use] revision numbers is just asking for trouble. > 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. I will absolutely refuse to make the joke that real programmers write code correctly the first time and that Java programmers never get it right no matter how many times they refactor their code <big evil grin>. > 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. Well, just look at all the fuss made that svn does rename and cvs doesn't. With remove/add to do an effective move you loose the history (and have to go back to the old file to get it... this is the biggest killer with it.) > A clever > CVS GUI can combine these commands easy to a rename/move action. Some of us work from the CLI. Automated build processes work from the CLI. The GUI is not the answer to everything (and IMHO GUIs are usually so poorly designed that they actually get in the way). > 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. There's no need to add more attributes; the existing ones are IMHO sufficient (i.e. state; filename; log). FWIW for renames you can already glark whats happened by looking at the output of the cvs log command. -- David Somers typographer/programmer/whatever