[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sam Steingold
Subject: Re: address@hidden: Re: rename in cvs]
Date: 11 Oct 2001 17:31:05 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107

> * In message <address@hidden>
> * On the subject of "Re: address@hidden: Re: rename in cvs]"
> * Sent on Thu, 11 Oct 2001 13:03:50 -0400 (EDT)
> * Honorable address@hidden (Greg A. Woods) writes:
> [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ]
> > Subject: Re: address@hidden: Re: rename in cvs]
> >
> > In article <address@hidden>, Greg A. Woods wrote:
> > >>  * 'cvs log BAR' does not list changes in file FOO
> > >
> > >Of course not!!!!  You do not want it to!  That would be illogical.
> > 
> > That is false. Just because the tool doesn't do something doesn't mean we
> > don't *want* it or that it is illogical. Some version control tools can
> > handle renames.  The actual object being version is stored anonymously,
> > and a path name is just another versioned property of that object.
> Let me repeat: You DO NOT want or need to have "cvs log BAR" list
> changes in the file "FOO".  To want that is illogical.  It is
> unnecessary!

Could you please elaborate?
_Why_ is it illogical?
_Why_ is it unnecessary?

Let me try to repeat: FOO and BAR here are the same file (like
compiler.lisp and compiler.lsp).
If FOO is renamed to BAR when it is at 1.125, then
the change from FOO 1.123 to BAR 1.3 is a matter of 4 modifications:

1. FOO 1.123 --> FOO 1.124

2. FOO 1.124 --> FOO 1.125 == BAR 1.1

3. BAR 1.1   --> BAR 1.2

4. BAR 1.2   --> BAR 1.3

Why can't I see the log for all of them in one command?

Consider a versioning file system which has a native idea of file
I can rename file FOO;<latest> to BAR;<latest>, keeping the older
versions of FOO named FOO;1, FOO;2 &c. - this corresponds to the CVS
method (rm/add).
But I also can rename _all_ version of FOO to BAR.
This _is_ a reasonable thing to do.

Why can't I do it with CVS?

Please note that the answers like "this is not how CVS manages change!"
are not very convincing, because the natural retort is "then maybe CVS
manages change incorrectly?"

Please tell us _why_ the request for the CVS command mv, which would
rename the *,v file and replace the CVS/Entries entry is unreasonable.
(Oh yeah, CVSROOT/history should also be suitably modified and a record
of the renaming to allow for undoing it should also be added.
But is these are too hard to implement, forget it and stick with a
simple "mv FOO,v BAR,v").

And while I am talking about undoing, why can't a revision be removed
from the CVS?  just like I can remove a revision in a versioning file
system, I should be able to remove a revision from the CVS.

Don't get me wrong.  CVS is a great tool.
Let's make it even better!

Sam Steingold (
Support Israel's right to defend herself! <>
Read what the Arab leaders say to their people on <>
The paperless office will become a reality soon after the paperless toilet.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]