In article <[EMAIL PROTECTED]>, Sam Steingold wrote: >> * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: >> >> [ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] >> > Subject: Re: [[EMAIL PROTECTED]: 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. ;) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
