[ On Monday, January 31, 2005 at 08:05:47 (-0800), Mark D. Baushke wrote: ] > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) > > If I move 'foo.c' to 'bar.c' the CVS/Entries file is going to be confused. > > In general, doing lots of bulk renaming and local 'cvs add' and 'cvs rm' > operations without contacting the repository could be useful in some > situations, but could be very confusing as well.
Indeed -- people (CVS users in particular :-) need to stop thinking in terms of "rename" and go back to the good old fundamental underlying concepts of creation and deletion. There is no such thing as a "rename" in most facets of computing. Even in the filesystem there's no such thing as a "rename". There's a rename() system call in all modern systems, but it just makes a link() & unlink() with appropriate locking to prevent clashes and so that it appears as one operation; Fundamentally it's still a link() followed by an unlink() and no amount of wiggling and worming with the English language can change that. For example if the power to the system is cut exactly in the middle of a rename() execution then both files might exist after a reboot, or the old file might have to be relinked by a filesystem consistency checker. However with any stable and reliable filesystem implementation that guarantees metadata consistency once the rename() call returns then only the new filename exists, and even if the power is cut immediately after the return completes all will be well after a reboot (with that filename, at least). I.e. an application calling rename() can be sure the link() & unlink() have both completed successfuly and securely once the rename() returns successfully. That's the only reason for making a combined meta-operation like link() and unlink() into a separate system call. CVS can implement a form of "atomic" rename too if the user is careful to always commit after each "mv a b; cvs rm a; cvs add b" sequence. Sites with untrained and/or careless users should probably use a wee tiny wrapper script to simplify this sequence for those users though (i.e. to emulate the OS rename() system call :-) Someone might someday even enhance the standard CVS client so that it can do all four operations in one sequence and to also create a uniform standard log message too so that reporting tools can sort out exactly what happened just by looking at the commit logs. If I were to implement such a meta-command I would only allow one pair of normal filenames to be specified so that each file rename would have to be done individually; but it is conceivable that someone else might even implement it so that it could combine all the sequences for all the files in a whole directory so that even a directory could "appear" to be renamed with one simple command. Such an implementation would just be a convenience feature though and the same underlying command sequences could still be issued independently by the user. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs