[Top][All Lists]
[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.
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), (continued)
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Greg A. Woods, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Mark D. Baushke, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Mark D. Baushke, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Paul Sander, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/19
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Paul Sander, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/19
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes),
Paul Sander <=
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Greg A. Woods, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Mark D. Baushke, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-partysources and adding/committing changes), Todd Denniston, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-partysources and adding/committing changes), Derek Robert Price, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Paul Sander, 2004/11/18
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/19
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Paul Sander, 2004/11/19
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Derek Robert Price, 2004/11/20
- Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes), Paul Sander, 2004/11/20