Re: address@hidden: Re: rename in cvs]

[Greg A. Woods]

[ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ]
> Subject: Re: address@hidden: 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      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>