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

[Sam Steingold]

> * In message <address@hidden>
> * On the subject of "Re: address@hidden: Re: rename in cvs]"
> * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT)
> * Honorable address@hidden (Greg A. Woods) writes:
>
> [ 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.

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.