Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)

[Derek Robert Price]

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

Paul Sander wrote:

>It's simpler, but neither safer nor saner to wrapper script around the
>client.  The reason is this:  If you enforce policy but give the user
>an avenue to circumvent it, the user will do so.  If you're serious about
>enforcing policy, then you must have a way to build it into your tools
>in a way that user cannot defeat.  In CVS (and indeed most if not all
>existing version control systems), that means spawning trigger scripts
>from within the tool, because wrapper scripts are trivial to defeat.


This argument is not applicable to workspace changes.  The user can
manually edit the CVS/Entries files to add or remove a file locally
without ever contacting the server.  Your proposed hook would never
run in this case.  This is a trivial hack and, in fact, there are
already scripts out there that will do just this without the user even
needing to learn the trivia required to edit the files by hand.  If
you truly believe that, "If you enforce policy but give the user an
avenue to circumvent it, the user will do so", then your proposed
hooks would offer absolutely no improvement over the status quo for
your reported purposes.

>>Remember the very strongest bit of advice for using CVS is to "update"
>>and to "commit" early and often
>
>
>This is true, but it remains a common belief that nothing should be
>committed until it's ready for unlimited use by the rest of the project.
>As long as that paradigm holds, work will continue to be done for long
>periods of time between commits.


Your users should be committing changes to branches until they are
ready for shared branches.  There is no excuse for what you describe
except ignorance or laziness.

>Claiming that the hooks are not needed in the context of current use is
>meaningless because the hooks do not currently exist.  Such arguments can
>only be made if one can demonstrate that existing hooks are not used in a
>meaningful way.
>
>On the other hand, we have stated requirements where existing users find
>existing capability to be inadequate.  This is compelling reason to add
>the requested feature.


Sure, if the user needs to request the feature using `-C'.  The would
be no other excuse for a needless server contact after Greg's proposed
patch otherwise (which states in detail the direction I've thought
development needed to go for awhile), except possibly if the add would
continue if the server contact failed, but the more I think about it,
the more I think even this is inappropriate without the user
specifying the option.

As I mentioned before, the user should have complete control over
their workspace.  This includes being able to add and remove files in
their workspace even when they do not have write privileges on the
server, much less without letting the server abort the addition via an
external script.  Any other solution would mean that users could not
generate complete diffs based on data they were not ready to commit.

(This problem of complete diffs is actually the status quo since add
still contacts the server.  CVS will not calculate a diff for files is
not tracking, at least locally, so to get new files into a diff, they
need to be added locally.  Unfortunately, this currently means
contacting the server and having write privileges in the repository in
question, which means that this cannot be done against an anonymous
repository, or indeed any where the user has no write privs, without
hacking the CVS/Entries file to add files by hand.)

>I define the "add" and "rm" commands as the actions required to make
>CVS aware of new artifacts or to remove them from existing
configurations.
>How it does that is to me an implementation detail, and I don't care
>whether or not the tool considers it necessary to contact the server.


They are the commands used to make CVS aware of the additions and/or
removals *locally*.  Commit is the command that makes the change in
the repository and thus visible to other users (with the obvious
exception of directories, currently, but this error is one Greg
proposed to remove.)

>However, in the event that triggers are added to track these events,
>they must be added in such a way that user's can't defeat them by
applying
>more primitive operators or munging their environment.


Again, a user can run primitive operators like `sed' and `vi',
regardless, to add or remove the file locally, and will continue to be
able to do so regardless, so this argument is moot.

Cheers,

Derek

- --
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBngVSLD1OTBfyMaQRAiHUAKD9yvhbzjx1qcPA3x9pDENo3dRYmwCfVgmz
Tbl9xZFi0Lsz8+Yp0nH3WsY=
=fhaq
-----END PGP SIGNATURE-----