On Nov 19, 2004, at 6:38 AM, [EMAIL PROTECTED] 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.
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
