[Top][All Lists]

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

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

From: Kaz Kylheku
Subject: Re: address@hidden: Re: rename in cvs]
Date: Thu, 11 Oct 2001 19:51:13 GMT
User-agent: slrn/ (Linux)

In article <address@hidden>, Greg A. Woods wrote:
>[ 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.

It's only not the same file because of the braindamaged version control
system which cannot represent that semantic idea! As far as the user is
concerned, it is the same file, under a different name.

Merely, the software has failed to capture the user's perfectly
sensible idea. Instead, it provided a half-baked emulation: delete the
old, recreate under new name.

This breaks seriously, for instance, under merging.  Suppose work takes
place on FOO on a branch. Then on the trunk FOO is removed, and a BAR is
created with identical contents, in order to emulate a rename.  When the
branch is later merged, the FOO patches will not be applied to BAR. Moving
the patches to BAR will require error-prone manual work.

This should be pereceived as enough of a problem to completely deter
clueful users form trying to rename files.  The best way to view CVS
is that it does not handle renames at all, so don't even think about
ever doing it using *any* of the methods recommended in the manual.

I can live without being able to view the complete history of the
object in one piece. But the other breakage, in particular merging,
makes it totally unacceptable to do a rename.

I accept the limitation only because CVS has open source code, a suitable
redistribution license, good reliability and a set of capabilities that
is good enough for many purposes. 

reply via email to

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