[Top][All Lists]

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

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

From: Paul Sander
Subject: Re: address@hidden: Re: rename in cvs]
Date: Thu, 11 Oct 2001 02:13:06 -0700

>--- Forwarded mail from address@hidden

>[ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ]
>> Subject: Re: address@hidden: Re: rename in cvs]
>> if you rename FOO to BAR "the right way", i.e.,
>> $ mv FOO BAR
>> $ cvs rm FOO
>> $ cvs add BAR
>> $ cvs ci BAR
>> then you lose in many ways:

>No, you lose absolutely nothing -- in fact you _gain_ the information
>about the rename!

This is only true if the user performing the steps above remembers to
include a comment.  The other thing is that because the rename isn't
atomic, it can be only partially completed and cause problems for other
developers caught up in the race condition.

A usable rename would have the following user model and store the fact
of the rename automatically:

cvs mv FOO BAR
cvs ci BAR

The mv would move the working copy and update the CVS sandbox state
as needed, ideally recording the fact of the move there to be stored
at commit time.  It would also have to be robust enough to be repeatable
(i.e. cvs mv FOO BAR; cvs mv BAR BAZ; cvs commit BAZ) and reversible
(i.e. cvs mv FOO BAR; cvs mv BAR FOO; cvs commit FOO) before the commit.

The commit would (in a single transaction) deaden the appropriate version of
FOO, create BAR (or resurrect it), create the appropriate tags (if the
sandbox is on a branch), and commit local changes.

But again, there are the fragmented history and ambiguous history problems.

>>  * 'cvs log BAR' does not list changes in file FOO

>Of course not!!!!  You do not want it to!  That would be illogical.

It's totally logical if BAR and FOO are the same file, BAR having been
renamed to FOO.  Remember, the version histories of BAR and FOO are
only fragments of the file's entire version history.

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

Not with the "cvs diff" command, it isn't (assuming BAR was renamed to FOO).
You must have both files checked out somewhere (and one usually isn't)
before the standard diff program will work.

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

The first point was:
---->  etc - CVS does not know that FOO is the old name for BAR.

That's the important part.  Fragmented version histories are a royal

>--- End of forwarded message from address@hidden

reply via email to

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