Re: 'cvs add' client/server semantics (was Re: Triggers)

[Greg A. Woods]

[ 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 <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>