[ 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're not making sense. 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. > you do not have to be rude. I wasn't -- I was merely pointing out that such an example is not relevant to this discussion since it is far beyond what most any file-based change control tool can ever do. > you do not know all the circumstances. > I was not the one who did it. I didn't claim to know the circumstances, nor who did it -- that's all mostly irrelevant. > In the similar situation I did the right thing - the renaming at the > file-system level, not the CVS level. Well, whether that would have been "the right thing" or not depends on several other factors..... > why? why can't "cvs mv" rename the *,v file? Nope -- no file-based change control tool can. You have to add a whole mess of meta-data on top, and the more you think about all the corner cases and side effects, the deeper the pile gets. Soon you end up building a system that's completely the opposite of a file-based change control tool -- i.e. one that constructs files out of sets of changes that are probably stored in a more sophisticated database than any unix-like filesystem can ever be on its own. > > The effect on the revision tracking of such a grand renaming is really > > no different than changing all the white space or indentation inside > > of every file. > > I do not buy this. > renaming a file does not change it's contents. but the EFFECT (on the change management process) is the same!!!!!!! Unless you understand this you will fail to understand the larger issue here! > > Such structural changes to a project are usually best done at a major > > milestone (eg. just after a major release) and at least with CVS are > > usually handled best by starting fresh with a new module. > > huh? you mean CVS is no designed to keep the changes over many years > and releases?! It all depends on many many many factors. In a simple and relatively straight forward project it works very well over extended periods of time. Take NetBSD or FreeBSD, or even the CVS-II source itself, for example.... > Emacs has `vc-rename-file' and it supports both RCS and SCCS. > Yes, this might not be native operations, but _this can be done_. I think you don't understand the larger issues here. What vc-rename-file does breaks all kinds of things in the larger SCM picture! It is a cheap hack that wise people would only use in very limited circumstances. > Thus, of all the tools accessible to me, only CVS refuses to rename > files. CVS refuses to rename files because the CVS designers were aware of all the deeper issues and they didn't want to create a situation worse than the current "alternative". > Would you like to use a file system which lacked rename(2) syscall and > instead required one to do the following: > $ cp FOO BAR > $ rm FOO well as a matter of fact the rename(2) call is a recent addition.... BUT, You're trying to compare totally unrelated things here -- it might look so simple on the surface, but when you have to keep track of such operations over time requires much more than a simple rename command! > > > please! how do I do that without going through this: > > > $ cvs co -p -r 1.123 BAR > BAR.1.123 > > > $ cvs co -p -r 1.321 FOO > FOO.1.321 > > > $ diff BAR.1.123 FOO.1.321 > > > > Huh? You have your result! What are you asking? > > I am asking that I do not have to be forced to jump over my head to > achieve a trivial result. "Jump over your head"? What kind of nonsense is that? The procedure is trivial! Why are you complaining about something so simple and obvious? Just do it! > yes of course! but the mistake has been done already, long ago, and I > wish I could undo it now. be careful what you wish for -- you may only create a worse nightmare. If I were you I would break from the past and start fresh. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs