> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > > > why? this is the same file. > no, actually it is not.
yes, actually it is. you want me to look at the world through the tool-imposed blinders. no way. these files are the same, period. the issue is that CVS does not recognize that. Actually, now that the damage (i.e., "the right way" - cvs add/rm) has been done, CVS really has no reason to recognize the truth and admit that the files are the same. But calling "cvs add/rm" "the right way" instead of adding "cvs mv" is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. > CVS tracks changes ... thanks for repeating this. actually, I knew all this, but it was nice to here that my knowledge was correct. > > to use a very specific example: CLISP (http://clisp.cons.org) used "lsp" > > extension for CL files but switched to "lisp" a couple of years ago. > Hmmm.... that's a very outrageous example of an idiotic change with > no productive end result. you do not have to be rude. you do not know all the circumstances. I was not the one who did it. In the similar situation I did the right thing - the renaming at the file-system level, not the CVS level. > > This was done "the right way" as per CVS manual. > > Now we have two totally unrelated (from the CVS point of view) files: > > compiler.lisp and compiler.lsp. > > Actually, from the human point of view, these two are the different > > names of the same file, and being able to see the change history of this > > file _is_ a reasonable and logical thing! > > CVS is simply not designed to manage such large-scale renames. They > are far beyond the design goals of a simple file handling tool like > CVS. why? why can't "cvs mv" rename the *,v file? > The effect on the revision tracking of such a grand renaming is really > no different than changing all the white space or indentation inside > of every file. I do not buy this. renaming a file does not change it's contents. > Such structural changes to a project are usually best done at a major > milestone (eg. just after a major release) and at least with CVS are > usually handled best by starting fresh with a new module. huh? you mean CVS is no designed to keep the changes over many years and releases?! > That way you are not tempted to do things that would be illogical in > the first place. The same is true with SCCS and RCS, and no doubt > with TCCS, PRCS, Aegis, Perforce, and other similar tools too. Okay. I have never used TCCS, PRCS, Aegis, Perforce and SCCS. Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. MS SourceSafe also can rename a file. Thus, of all the tools accessible to me, only CVS refuses to rename files. Would you like to use a file system which lacked rename(2) syscall and instead required one to do the following: $ cp FOO BAR $ rm FOO Let me repeat again: file renaming is a reasonable operation and it must be supported in a reasonable way. Just like cp+rm is not a reasonable replacement for mv, cvs add/rm is not a reasonable replacement for cvs mv. > > > > * there is no way to compare BAR 1.123 with FOO 1.321 > > > > [yeah, they are separated by over a hundred revisions, so what? > > > > there are still situations when this makes sense.] > > > > > > Bull. It's trivial to do. > > > > please! how do I do that without going through this: > > $ cvs co -p -r 1.123 BAR > BAR.1.123 > > $ cvs co -p -r 1.321 FOO > FOO.1.321 > > $ diff BAR.1.123 FOO.1.321 > > Huh? You have your result! What are you asking? I am asking that I do not have to be forced to jump over my head to achieve a trivial result. > > Let me repeat: I have two files: <compiler.lsp,v> (with _many_ revisions) > > and <compiler.lisp,v> (with even _more_ revisions). > > I need to create a file compiler.lisp,v with _all_ these revisions, > > sequentially, first those from <compiler.lsp,v>, then from > > <compiler.lisp,v>. > > I think you are asking the wrong question. > > You have not stated the base requirement which seems to be driving > your desire to do this. I want to be able to see the change history for compiler.lisp &c. > If your goal is simply to forget that you ever had *.lsp files then > obviously it would have been easier to simply rename them in the > repository. yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. > The best process for your situation depends on many factors you have > not described to us, such as whether or not you have other active > branches, and whether or not you have previous releases that must be > retained, and also whether or not you have renamed any other files in > the past too. there are no branches, but there are many tags ("symbolic names" in cvs log) and they must be preserved. > > The only thing I can think of is: check out <compiler.lsp> and patch it, > > one by one, with all the patches that went into <compiler.lisp>, then go > > (using shell) into the CVS repository and rename <compiler.lsp,v> to > > <compiler.lisp,v>. > > Why do you care so much about connecting these revisions? You can > easily connect them externally, by hand in effect, in the undoubtably > very few cases any detailed analysis of their past history is > necessary. aesthetics. :-) I will probably not end up doing this. I am just trying to tell you that the absence of "cvs mv" leads to very unpleasant results for the users. > > The problem is that there are 64 such files, so this process will have > > to be automated somehow. > > Yes, of course, but that's trivial for anyone handy with any command > scripting language and who is knowlegable of the tools involved to do. yes. > The result in the ,v files is identical (except for maybe some > timestamps). ouch!!! this makes the above (patching the old file with the new patches) unacceptable: the patches will be dated incorrectly! thus, we actually do need an "rcs-file-merge" operation: take two rcs files FOO,v and BAR,v and make a new file ZOT,v so that ZOT;1.* are the same as FOO;1.* and ZOT;2.* are the same as BAR;1.* > > I hope I made my needs quite clear already. > > You need to do a "cost/benefit" analysis to see if the hassle of > re-building your repository is worth the effort -- i.e. will you ever > spend any more time and effort analysing past revisions to make this > up-front effort pay off? probably not. but all this proves is that we need "cvs mv"! -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> Murphy's Law was probably named after the wrong guy. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
