[ 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. You are not properly understanding how CVS uses filenames and how it manages change to those files. CVS tracks changes to the contents of files by using their filenames as anchors in the directory structure. It knows nothing of what's in the files though, nor of their relationship to each other (except of course for their names and their hierarchical position in an underlying directory structure). It does this by effectively taking snapshots of the contents of the files and storing them in RCS files in the repository. The repository directory structure is laid out exactly as the working directory's structure is so as to make all of its operations one-to-one on each file in a module (with the exception of some optimisations it uses in the repository to avoid wasting time on dead files). If you take away a file then CVS marks it as dead and stops copying its old contents to working directories. If you add a file CVS starts tracking changes to that file (again if it was previously dead). There is no concept of a rename because CVS does not try to intuit that a newly added file's contents look a lot like some other removed file's contents. Just as in any simple relational database there is only an "add" and a "delete" operation and change is expressed through a combination of these operations. If you wish to remember that you've moved the contents of one file to another file then you need to do this in the same way you remember any other change -- i.e. with a commit comment. > 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. > 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. The most obvious logical approach to renaming those files would have been to add another intermediate step to your build process to do the rename at build time. 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. No change control tool, especially none which has zero understanding of the semantics of the files it manages, can cope in either of these examples. In other words for the example you describe the result is illogical from the very beginning -- to ask for CVS to now treat two different files as one is therefore equally illogical. 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. 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. > > > * 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? CVS is not a programming language. Do we have to add that to the manual too?!?!?! Why is it that people are often blinded to the obvious when they are given a tool that combines many operations but not all operations? Perhaps everyone should do without RCS and without CVS for some small project and track every change to every file manually for a time. Then you would not so easily forget how to do such things when you use CVS! > > > --> etc - CVS does not know that FOO is the old name for BAR. > > > > > > * also, this operation cannot be undone gracefully: when I do the above > > > renaming backwards, CVS moves BAR,v into the attic and there is no > > > way to get the revisions of BAR into the FOO,v file > > > (or is there - how do I concat two *,v files?!) > > > > It's trivial to "undo" too -- the same way you "undo" any commit. > > okay. I _really_ do need this, and I will greatly appreciate an > instruction on how to do this. > > 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. 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. 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. > 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>. Yes, that will accomplish what you've said you want to do..... but why? 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. > 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. > BTW, is there any difference, from the CVS POV, between > > $ cvs ci -m mesg FOO BAR > and > $ cvs ci -m mesg FOO > $ cvs ci -m mesg BAR > ? Yes there is a difference, but only in the commitinfo and loginfo processing.... The result in the ,v files is identical (except for maybe some timestamps). > the reason I am asking is that some files have been checked in together, > so I will need to do some trickery to check the diffs into the old names > together too. > > > > The problem is that I do not always have shell access - then I am stuck. > > You don't need to have shell-level access to the repository. > > this is very nice to hear. > > could you please tell me what to do? You're already on the right track -- you simply need to employ existing CVS commands since those are your sole access to the repository. > I hope I made my needs quite clear already. Well, your stated goals are clear, but the reason for them is more fuzzy than ever. 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? I seriously doubt it. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs