info-cvs
[Top][All Lists]
Advanced

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

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


From: Greg A. Woods
Subject: Re: address@hidden: Re: rename in cvs]
Date: Fri, 12 Oct 2001 18:32:54 -0400 (EDT)

[ On , October 12, 2001 at 13:51:10 (-0400), Sam Steingold wrote: ]
> Subject: Re: address@hidden: Re: rename in cvs]
>
> Also, the manual does _not_ explain why cvs cannot do what is described
> in <http://www.cvshome.org/docs/manual/cvs_7.html#SEC72> with "cvs mv"
> and <http://www.cvshome.org/docs/manual/cvs_7.html#SEC73> with "cvs cp".

Well, the "Moving the History file" method really should not be
documented in the first place.  It is a very seriously dangerous hack
that even knowlegable people should not attempt (it's way too easy to
make mistakes).  I think the only reason it got into the manual was
because so many people naively tried it and then whined about the
resulting problems that documenting its problems up front was the best
way to convince people to not do it.

As for why CVS doesn't internally implement either of the latter two
schemes, well the reasons should be obvious.  The former is simply far
too dangerous and can cause major damage to a repository -- damage
that's impossible to undo without having a trace of the commands that
caused it.  The latter is extremely tricky to get right too, and
impossible to do automatically in some scenarios; and given the
additional disadvantages I outline below it's questionable as to whether
it should even be documented.

> especially the last one which has only one disadvantage --
>  * You cannot easily see the history of the file across the rename.
> whose meaning I don't understand.

That's a pretty major disadvantage in the larger scheme of things.  You
cannot any longer discover that the file was renamed just by looking at
it or at its history.  (Actually there is a trick that helps, but I'm
going to be nasty and not tell you what it is!  ;-)

There are also other very serious disadvantages that the released manual
does not explicitly list:

        @item
        This method fails in drastic but hidden ways if
        @var{new} ever existed previously and had been
        subsequently removed.
        
        @item
        This method fails utterly for files with branches.
        
        @item
        This method requires direct access to the repository.
        
        @item
        You cannot use @address@hidden to safely retrieve
        previous revisions.

Of course there are some large projects which have decided to go about
doing renames using this policy regarless (eg. NetBSD).

-- 
                                                        Greg A. Woods

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



reply via email to

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