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

[Greg A. Woods]

[ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ]
> Subject: Re: address@hidden: Re: rename in cvs]
>
> 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.

You're not making sense.  You need to understand the much deeper issues
of trying to include rename information in a change control tool, You
really cannot add such a feature to a file-based change tracking tool --
doing so takes you far away from what CVS is.

> you do not have to be rude.

I wasn't -- I was merely pointing out that such an example is not
relevant to this discussion since it is far beyond what most any
file-based change control tool can ever do.

> you do not know all the circumstances.
> I was not the one who did it.

I didn't claim to know the circumstances, nor who did it -- that's all
mostly irrelevant.

> In the similar situation I did the right thing - the renaming at the
> file-system level, not the CVS level.

Well, whether that would have been "the right thing" or not depends on
several other factors.....

> why?  why can't "cvs mv" rename the *,v file?

Nope -- no file-based change control tool can.  You have to add a whole
mess of meta-data on top, and the more you think about all the corner
cases and side effects, the deeper the pile gets.  Soon you end up
building a system that's completely the opposite of a file-based change
control tool -- i.e. one that constructs files out of sets of changes
that are probably stored in a more sophisticated database than any
unix-like filesystem can ever be on its own.


> > 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.

but the EFFECT (on the change management process) is the same!!!!!!!

Unless you understand this you will fail to understand the larger issue
here!

> > 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?!

It all depends on many many many factors.  In a simple and relatively
straight forward project it works very well over extended periods of
time.  Take NetBSD or FreeBSD, or even the CVS-II source itself, for
example....

> Emacs has `vc-rename-file' and it supports both RCS and SCCS.
> Yes, this might not be native operations, but _this can be done_.

I think you don't understand the larger issues here.  What
vc-rename-file does breaks all kinds of things in the larger SCM
picture!  It is a cheap hack that wise people would only use in very
limited circumstances.

> Thus, of all the tools accessible to me, only CVS refuses to rename
> files.

CVS refuses to rename files because the CVS designers were aware of all
the deeper issues and they didn't want to create a situation worse than
the current "alternative".

> 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

well as a matter of fact the rename(2) call is a recent addition....

BUT, You're trying to compare totally unrelated things here -- it might
look so simple on the surface, but when you have to keep track of such
operations over time requires much more than a simple rename command!

> > > 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.

"Jump over your head"?  What kind of nonsense is that?  The procedure is
trivial!  Why are you complaining about something so simple and obvious?
Just do it!

> yes of course!  but the mistake has been done already, long ago, and I
> wish I could undo it now.

be careful what you wish for -- you may only create a worse nightmare.

If I were you I would break from the past and start fresh.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>