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

[Greg A. Woods]

[ On Sunday, January 30, 2005 at 22:24:06 (-0800), Mark D. Baushke wrote: ]
> Subject: Re: 'cvs add' client/server semantics (was Re: Triggers)
>
>   - there are good reasons for 'cvs add' to have an advisory process
>     (which becomes an enforcement at cvs commit time)
> 
>     a) inform the user early that a proposed addition will fail at such
>        a time that the user does a 'cvs commit' so as to minimize the
>        amount of work that is done under a mistaken assumption that the
>        commit would succeed.
> 
>     b) provide for a simpler kind of trigger implementation to just
>        implement policy on newly created files at commit time.

Those two are logically the exact same "reason" (the first is just a
specific form of the second), but neither are valid for CVS:

The user has the option of doing an immediate "cvs commit" of an empty
file if he or she wants to know if the filename is acceptable to the
repository.  The core CVS program must not force these kinds of timing
decisions on the user.  Besides t

If a shop wants to enforce this kind of policy with some kind of
technical control then they have the option of writing a wrapper program
that has a "create file" feature which will create an empty file, "cvs
add" it, and then immediately "cvs commit" it.

A shop also has the option of writing their own CVS client that combines
the "cvs add" and "cvs commit" operations into one so that a file must
always be immediately commited (even if empty, just to reserve the name).

A shop also has the option of writing wrappers, or alternate client
programs, that use other repository server programs to check repo
policies at "cvs-wrapper add" time.

None of the above require any server contact to be done in the core CVS
program within its basic "cvs add" function -- they can all be done
externally in those few places where someone might think they are
necessary.


>     c) the addition of pre-<event> and post-<event> triggers to cvs
>        commands that presently modify the repository allows more control
>        for a cvs administrator to enforce policy pro-actively.

This kind of nonsense goes way beyond the basic change tracking
functionality of CVS and tries to turn CVS into a project management
tool.  Such things are best done by additional tools since they have an
extremely narrow application in a very limited number of shops.

The *info scripting hooks in CVS are only intended to make site
customization possible for things like reporting functions, and to
provide hooks for for very basic consistency checks.

CVS is supposed to keep out of your way, not get in your face at every
point you interact with it.


> Certainly he is not suggesting
> any client/server protocol change and the addition of a trigger is very
> simple to accomplish.

Well actually he is requiring a protocol change -- at least if it's to
be done right.  And remember he'd likely also want "cvs rm" triggers.

> No client changes are required, so only the server
> needs to be upgraded to add the new functionality.

Again, to do it right I think it would -- and then there's "cvs rm"....


> Greg's arguments for not contacting the server on a 'cvs add' would
> require the semantics of a 'cvs commit' to be extended to allow for new
> directories to be created

Well it depends on what level you're looking at, but no, 'cvs commit'
semantics are not really changed -- my complete "cvs add" revamp already
covers this whole issue.

Remember directories are not tracked in any way -- they're just
placeholders for filenames.  They simply come and go as required.  If
there are files to go in a directory then the directory has to exist,
and if there are no files to go in it then it does not exist (though of
course files are never really removed in the repository since their
history must be preserved, but that's already handled by the prune
option (which shouldn't be an option -- it should always happen).


> So, from an implementation point of view, it would appear that Paul's
> proposal is easier than Greg's.

They're not even really related -- my "cvs add" proposal simply fixes
the long standing problems and bugs to bring it in line with "cvs rm"
from a UI perspective.

Paul's proposal is only really about adding server hooks to all client
commands.

The only reason my proposal pushes Paul's "I have to have total
centralized control" hot-button is because I take away one of his
potential points of control -- one he should never have been able to
consider as possible in the first place.  He spends a lot of time and
effort arguing for total centralized control over the client operations,
but he lost that argument the day he considered CVS in the first place,
except of course he had a taste of CVS before it was split into a
client&server application and he seems to still long for the bad old
days of a monolithic single program.

Sergei is right -- Paul should only give his users dumb terminals and he
should require them to login directly to his central development machine
so that he can control every keystroke his users make.

-- 
                                                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>