I have a few concerns about client side hooks:
- Security for the user.
- There are real compatibility problems with client hooks, and many of
the tasks can be achieved equally well on the server.
** Security **
I think my chief concern is this: I read about some interesting open
source project on the net and decide I want to check out the code and
have a look. I svn checkout the code, and the client hooks covertly
subvert my system.
I think that making subversion give the repository direct exectuion
priveleges on my system by default is a mistake. Almost no one can
remember to always disable client hooks everytime they access an
untrusted repository. (Just look how poorly people listen to advice
not to open executable attachments.) If svn gives me a way to enable
client hooks for a particular repository or a particular working
directory, then, as long as the default is disabled, this might be
ok.
Regardless, the server is a better place to do many of the examples
you gave, anyway.
** Compatibility **
As you allude to near the end of your message, client-side hooks would
depend at the very least on the OS of the host. In fact, having dealt
with this type of thing before, I've found that it tends to depend on
a lot more than that.
In my project, we had development on windows and solaris mostly. We
needed to have code run to setup a working directory after checkout
and after updates to certain files. If we had had the possiblity of
client side hooks, we might have used them since the setup code was a
noop if it didn't need to do anything. We had some compatibility
problems with Solaris, but Windows was the real pain. Some computers
didn't have the MKS korn shell installed. Some had Cygwin installed
instead. Some didn't have Visual C++ installed. And so on and so
on...
Of course, if you are a company with a good IT staff, you may be able
to standardize the machines enough to make this work, but we found the
problem more difficult than most people originally expected.
If the project is an open source project where the participants'
machines are not maintained by a common IT staff, then this gets
tricky indeed.
** My Conclusion **
Client hooks may be a desired or needed feature, and these problems
may be solvable, but I think they need to be thought about carefully.
Chris
On Sat, May 25, 2002 at 02:27:36PM +0200, Josef Wolf wrote:
> # refuse commit unless regression tests pass and changelog exists
This might better belong on the server. You can't enforce a client
hook, since anyone could hack the client not to perform it anyway. As
a result, most types of commit fitness tests belong on the server.
One idea for reducing server load is to take a page from ageis and
modify it for svn. Under Ageis, when you run tests or you integrate
the build or anything else that the Ageis system wants to verify that
you have done before it proceeds, the results of the operation (output
of the test suite or whatever) are checked in with the changes. This
allows the server verify that your test results match the expected
results. (You include the checksums of the source or whatever if you
are worried about simple cheating.) This system is no easier to fake
than the client hooks, and doesn't load the server.
Oh. It just occured to me that this system also ensures that the
tests run in your environment (ie. on the local OS). Running on the
central server would not guarentee that.
>
> # announce the commit
The subversion project already does this with a server side hook.
Also, the server is known to be setup to send mail. My client box
isn't configured to do so, so it makes sense that it be done at the
server.
> # export automatically builds and uploads to server
I don't really understand the motivation for this. I sometimes export
from a repository because I want to, for example, import into a local
repository or do something else which is not really release based.
I'm don't understand the value of saving the state at that export
(especially since it should be possible to replicate it later if I
know the revision number when I exported).
> This could be extended to include the OS-name or hostname, so you
> could make:
>
> svn propset svn:export:post:Win c:\\command.com post-export.bat
> svn propset svn:export:post:Linux /bin/sh post-export-linux.sh
My experience (as I mentioned above) is that OS type (for example) is
too course-grained to do really make this type of stuff work in a
complex situation. Using hostnames would be really difficult to
maintain.
--
Chris Sloan
cds@cs.hmc.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 25 21:21:29 2002