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

[Kaz Kylheku]

In article <address@hidden>, Sam Steingold wrote:
>> * Honorable address@hidden (Greg A. Woods) writes:
>>
>> [ 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 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.
>
>why?

Because you would have to either change the representation of the
repository, or implement a whole indirection layer over CVS so that the
repository contains only ``anonymous'' objects which are assigned to
locations in a sandbox tree through some auxiliary binding.

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

Because then if you check out (or export) an old tagged build of the
software, it will have the rename. And that will very likely break the
old build.

A fundamental principle of version control is that when you label some
release of the software, it is fixed for posterity. Anyone can go back
and retrieve that release exactly.  This capability essential if you
ever need to go back to that version and shoot off a bugfix branch,
for instance.

In CVS, you can no longer do this if you start moving around the *,v
files. 

If you can't go back to tagged builds, then your version control system
is reduced to a mere piece of collaboration ``groupware'' at best,
and a file backup system at worst. ;)