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

[Mark D. Baushke]

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

Paul Sander <address@hidden> writes:

> Wait a second.  The "OK for addition, but wrong for commit" is exactly
> the status quo.  The "cvs add" command succeeds, "cvs commit" fails
> due to commitinfo.  What I'm proposing is "bad for addition, bad for
> commit", where "cvs add" fails on those occasions when we know at that
> moment that "cvs commit" will also fail.  That's not to say that we
> will *always* know at add time that the commit will fail; failures can
> occur due to problems in their content which are clearly not ready to
> check at add time.

I find that concrete examples are useful...

Does this one illustrate the usefulness your suggested change?

  Consider a shop which has a majority of folks using either UNIX or
  Windows clients as their primary development base. A file exists the
  mymodule/directory called 'MyFoo.h,v' and the local policy is that
  once a file has been added to the repository, no new file that a
  difference only in the case of the filename may be committed to that
  directory should be different only in case. So, the addition of a file
  named 'myfoo.h' to the directory should be allowed. The commitinfo
  will make this check as a part of the policy.
  
  If there were triggers for 'cvs add', then those triggers could notify
  the user that adding 'myfoo.h' conflicts with the existing 'MyFoo.h'
  which would possibly stop a lot of modifications that
  '#include "myfoo.h"' from doing the wrong thing that would otherwise
  only be caught by the 'cvs commit' triggers later.

In this case, a UNIX user may have forgotten that when a windows user
checks out 'MyFoo.h' there is no room for a new 'myfoo.h' to exist in
the same directory.

It is also possible that the 'policy' being enforced would be that no
mixed-case .h files should live in such a directory, so that only
'myfoo.h' would be allowed to be added in the first place.

Now, I will grant that it is certainly possible for a user to 'fix'
their checked out tree to work around this problem. However, it may be
desirable to get it right the first time rather than waste time later.

However, I am not sure how this argument for an advisory trigger at
'cvs add' time which then becomes a manditory 'enforcement trigger'
at commit time would not also be potentially very confusing to the 
users.

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

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

  - 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

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

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

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

    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. If the
       'cvs add' commands continues to allow modification of the 
       repository (creation of new directories), then there needs to be
       a way to catch abuses of policy.

So, it comes down to a choice of how should the 'cvs add' command
operate going forward and where is the correct place to add 'enforcer'
triggers for the administration of a repository.

I am finding Paul's arguments for additional flexibility for the
repository administrator to have more proactive control over the
repository to be an interesting approach. Certainly he is not suggesting
any client/server protocol change and the addition of a trigger is very
simple to accomplish. No client changes are required, so only the server
needs to be upgraded to add the new functionality.

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, but one of his new clients should be able to
do the right thing with an existing server by actually sending the 'cvs
add' command first for directories (assuming there is an easy way to
keep track of a locally created directory) and then following with a
'cvs commit' later. Although, it seems that a number of places in the
client will be impacted to remember that a locally created directory
should not be traversed when talking to the server (cvs log, cvs status,
cvs diff, cvs history, ...).

Note: It would still be possible for the server-side "cvs add"
capability to be given an 'enforcement' trigger even with Greg's changes
that 'cvs add' no longer be contacted by new clients until a
"cvs commit", but I get the impression that Greg would object to this 
change.

So, from an implementation point of view, it would appear that Paul's
proposal is easier than Greg's. However, it is not necessarily true that
taking the 'easy' path is the right thing to do.

Have I missed any arguments pro or con?

Are there any additional complexities of either implementation change
that should be considered for protocol compatibility?

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

iD8DBQFB/c8F3x41pRYZE/gRAsmXAJ9Jeb/fbtN/ZTb26BjOmXSWyLAuJACgjFEw
+17ZfAVF3/KpmtiSMYEyDAw=
=Kqgm
-----END PGP SIGNATURE-----