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

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sander <address@hidden> writes:

> On Jan 30, 2005, at 10:24 PM, address@hidden wrote:
> > At present, it is clear from both sides that the 'cvs add' behavior is
> > broken. I have probably missed some of the points, but let me try to
> > summarize:
> >
> >   - a new directory that is added with 'cvs add' does not go thru any
> >     peremptory enforcement checks at all (a cvs add trigger OR a policy
> >     that cvs add is a local-only operation would partially fix this
> >     provided that some other trigger addressed the creation of a new
> >     directory in the repository).
> 
> I'm not sure I fully understand what was said in this paragraph, but
> I'd like to say that I believe that adding directories should also be
> triggerable events, and that policies enforcing directory additions
> could be potentially different from policies enforcing file additions.
> Expanding on Mark's example, a second policy might require that
> directory names can not contain period (".") characters.  To make this
> happen, the trigger must be aware of the kind of artifact that's being
> added.

At present, a 'cvs add' will create a new directory and the 'loginfo'
trigger will be run with the new directory name given to the script. So,
the cvs administrator has no option to fail the 'cvs add' operation
before the new directory is already part of the repository.

That is to say, that 'cvs add' does have a trigger it uses, just that it
is not useful to a preemptive action.

> >   - related to this, the 'cvs import' functionality is likewise
> >     'broken' as it currently may stomp on existing tags and could
> >     create files and directories that are not acceptable to an
> >     administrators policies. There are presently no enforcer
> >     triggers that prevent a particular user from doing an import
> >     into the repository.
> 
> This is true, and integrating triggers into import requires a lot of
> thought.  I would suggest as a topic of discussion that import should
> scan the input tree and run all triggers in advance of the first
> change of persistent state.  But this is a very touchy subject because
> the vendors that make the drops may in fact make changes to the tree
> that violate local policy.  The CVS admin is then faced with a
> dilemma:  Should the tree be imported as-is for accurate tracking of
> vendor drops, or should the tree be adjusted according to local policy
> and potentially breaking the vendor drop?

That would seem to want to be a knob in the CVSROOT/config file for
setting policy. However, at the least, I'd suggest that passing the
names of the tags to be used for the vendor and version to the 'taginfo'
trigger is probably desirable to try to stop folks from stomping on an
important tagname that might already exist in a previously imported
revision.

> >   - there are good reasons for both 'cvs add' and 'cvs rm' to be
> >     considered as local operations that should not contact the server:
> >
> >     a) allows read-only users to generate 'cvs diff -N' output to send
> >        to a maintainer
> 
> I think this is common only when the user has read-only access to the
> repository, correct?

Yes. Or, when a user is using a 'guest' account for read-only mirror
rather than the read-write accout she may be entitled to use with the
primary repository that may be hidden behind a firewall of some kind.

> >     b) lets the local user experiment with re-oranization of the
> >        hierarchy of a module. (It is unclear if there would be any
> >        easy way to 'rename' files in the local tree and resolve them
> >        in a reasonble manner with the cvs server at a later date.)
> 
> Depends on what you mean by "resolve".  After mv'ing a directory in a
> workspace to something new, CVS still maps it to its original location
> in the repository.  If you're thinking about somehow having the rename
> be reflected in the repository, then you're treading dangerously close
> to another heated argument.  :-)

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.

I was trying to outline what I thought I read as reasons behind the
desire that 'cvs add' and 'cvs rm' operations should all be local.
It is possible that I have misrepresented them.

> >     c) allows a user to continue to do useful work even when access to
> >        the server is unavailable (it might be down for maintenance, or
> >        the user may be working from a disconnected network).
> 
> Yes, this is an issue.
> 
> >   - 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.
> 
> I'd go a little further and say this:  Inform the user early that *an
> attempted* addition will fail at such a time that user does a 'cvs
> commit'...

Okay.

> >     b) provide for a simpler kind of trigger implementation to just
> >        implement policy on newly created files at commit time.
> 
> I'm not sure this is an issue.  Would you elaborate, please?

Right now it is possible to use commitinfo to reject the commit of file
that has just been added via 'cvs add' during the 'cvs commit' phase.

I was trying to capture your desire to have a separate trigger that is
run as a part of the cvs commit step that enforces the 'cvs add' rules.

>...

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFB/ldb3x41pRYZE/gRAlR1AKCnhJMPK1LmTc/6yF5mDs8Iw+1CAQCfVo36
JsxT0jt2shu8eP9RmYMp6IM=
=onnU
-----END PGP SIGNATURE-----