info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: add hook question (was Re: Problem with importing third-party source


From: Paul Sander
Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
Date: Fri, 19 Nov 2004 15:35:08 -0800


On Nov 19, 2004, at 6:38 AM, address@hidden wrote:

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

Like I said in an earlier post, I also don't believe that the user should be given the ability to corrupt his metadata. But I won't argue about it, and acknowledge that with CVS it's a possibility.

Also recall that there was agreement that the add hooks should fire before the commit triggers at commit time, so whatever they do would be done regardless. It's just a matter of timing. And if the user bypasses the trigger and gets bitten later, so be it.


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.

I agree.  But I play with what I'm dealt.

BTW, using the submit/assemble mechanism discussed here in the past, it is possible to commit to shared branches under certain conditions and still have an efficient (and very livable) process. But that's a different topic.


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.

Looks like this part of our argument boils down to whether or not the trigger should fire by default. You say no, I say yes. However, we can have our cake and eat it too, if add-time hooks are implemented in the following way (which I summarize from prior posts):

- Register add-time hooks in a new *info file.
- Invoke the registered script at both of the following times:
  - User invokes "cvs add"
  - User invokes "cvs commit", before commitinfo triggers fire.
- Give the user the ability to defeat the add-time trigger in one of two ways: - Turn it on by default but use -n at add time to skip it, as I recommend.
  - Turn it off by default and add a new option to invoke it.



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

Okay, I'm convinced.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]