[ On Wednesday, February 2, 2005 at 15:33:28 (-0800), Mark D. Baushke wrote: ]
> Subject: Re: CVS diff and unknown files.
>
> Greg A. Woods <[EMAIL PROTECTED]> writes:
> >
> > Yes -- we are in almost full agreement, but it cannot use '-n'. (no
> > commitinfo scripts are run with '-n' and I don't think they should be or
> > ever need to be)
>
> I believe this statement does not reflect the current state of cvs.
You're right of course. "cvs -n commit" does contact the server (as it
should of course) and it does run any "commitinfo" scripts. I was no
doubt confusing "commit" with "add" when I made that claim.
But this just makes it even easier to answer Paul's idea for a server
based technical control over file naming. He simply needs to write a
commitinfo script that checks new names against his file naming policies
and then instruct his users to "cvs -n commit newfile" whenever they
want to check their new filenames against the server's policies. They
don't have to commit empty files and they don't have to
In fact his new customized CVS client could even combine these
operations, and any wrapper/front-end program could trivially do so as
well.
> In addition, the current 'cvs' requires that you actually contact the
> server to cause a new directory to be added.
Well, yes, but that's clearly a bug -- ans something that "we" have all
wanted to fix for a very very VERY long time now.
It is a bug that should have been fixed when the client and server parts
of CVS were first separated.
There never was any fundamental requirement for creating a new empty
directory in the repository -- it was the way it was done internally
before CVS was ever split into client and server, it's still just a
cheap, poor, hack that only slightly simplifies one minor aspect of the
internal implementation. I think use of a simple stack structure would
easily avoid this nasty hack, though fixing the code while the code
still implements the stand-alone unified non-C/S variant would still be
a bit complicated, but it wouldn't be hard to re-implement the non-C/S
variant as a client and server that communicate through a pair of local
pipes (that might even allow for clean-up of a lot of code!).
Another reason it's a bug is that most people I know (myself included :-)
feel that making any change to the repository that doesn't go through
"cvs commit" is just plain wrong, never mind that "cvs add" can also be
used as a kind of denial-of-service attack against one's colleagues,
and even when SSH is used the normal auditing trail for making changes
to the repository is not followed and no record is even made in the
history file (if one is being used), so significant forensic work would
be needed to identify the culprit, especially on a busy server.
In fact these reasons were all part of the impetus behind my re-design
of "cvs add" in the first place. (along with the desire to replace "cvs
import" once and for all as the way to create a new non-vendor module
from an existing set of project files, and of course with the goal of
making "cvs add" a true and complete match for "cvs rm" in its design)
--
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
