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

[Paul Sander]

On Feb 1, 2005, at 12:47 PM, address@hidden wrote:

> [ 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).

Committing empty files may not be permitted by project policy.  Many 
shops don't permit committing files until the code compiles.  (This is 
not a policy I agree with, but I have seen it in my shops.  The theory 
is that anyone should be able to get working code from any update, but 
I think there are better methods.)

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

And this is better, cheaper, faster than adding the capability to CVS 
in what way?  (Yeah, yeah, yeah, because it wasn't....   Given that 
proposed add-time triggers are optional on both the client and server 
side, the argument is vacuous.)

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

Given that the proposed add-time trigger is optional and reverts to 
what you call CVS' "basic cvs add function", the fact that triggers can 
be done elsewhere does not necessarily mean that they should be.

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

No, it does not try to turn CVS into a project management tool.  It 
enables CVS to integrate with one.  There's a difference, and I find 
that tightly integrated environment tend to work better.  By "tightly 
integrated" I mean a collection of tools that freely exchange data in 
meaningful ways and spawn or sense actions taken in other tools.

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

Ah, this statement suggest that you believe that policies are serving 
and that automatic enforcement serves only to hinder progress.  In my 
experience, the best policies have the following qualities:

- Understood and agreed upon by the entire team.
- Automated to the full extent possible.
  - Tedious tasks are fully automated.
  - Default tool settings produce proper results.
- Errors are detected as early as is practical, while they're easy to 
fix.
- Error correction is not hindered.
- Users produce correct results, unaware that policies are in fact 
being enforced.

In the end, the right product pops out the end of the process, with an 
acceptable level of quality, almost as a natural consequence (or even 
side-effect).

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

I haven't asked for them.  I have not yet experienced demonstrable harm 
in their absence.  That doesn't mean I won't ask for them at some time 
in the future.

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

And while we're at it, how about "cvs admin"...

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

No, I don't really want total control over all client operations.  But 
I would like more opportunities for the server to say "no".  And in the 
specific case of "cvs add" it would be useful to warn the user earlier 
that certain classes of errors have been detected and that he might 
consider changing directions before it becomes a problem.

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

That's an exaggeration.  I really don't want to control every 
keystroke.  I just want to keep them on the path they've agreed to 
take, because it's easier to stay there than to wander off and find the 
way back.

--
Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.