On Sun, May 26, 2002 at 10:41:46PM +0200, Josef Wolf wrote:
> On Sat, May 25, 2002 at 12:20:27PM -0700, Chris D. Sloan wrote:
>
> > I think that making subversion give the repository direct exectuion
> > priveleges on my system by default is a mistake.
>
> Right. Such an extension would require a command line switch to enable
> the hook-execution. The default should be not to execute the hooks.
In addition to command line args, I'd want a per-repository and/or
per-working directory way to enable the hook execution. For example,
if you use Subversion at your company, then it might make sense to
enable hook execution for the whole repository (or a subset thereof).
Then you could just forget about it since you trust the other
developers at your company.
The per-working directory control of hooks might be needless
complication, but here was my thinking: If you had some type of
sandbox, you could run the hooks in there, but you wouldn't want to
run them in working directories not in the sandbox. A similar
situation is if your config is in you NFS homedirectory, but you have
working directories on multiple machines. You could enable hooks on
some machines but not on all. (Say the hooks only run on certain
machines.)
> > One idea for reducing server load is to take a page from ageis and
> > modify it for svn. [ ... ]
>
> Are you talking about Aegis (note the spelling) or about yet another
> SCM? Yes, Aegis has many fine Ideas. It would be nice to see some
> (most?) of them in svn, too. But I don't think this will happen
> before svn-3.0 or some such.
I took the observed behavior of aegis and adapted it so that I think
it would work on Subversion. In particular, the key idea was that the
checkin operation included the "proof" that you did the needed
operations (in this case ran the tests). Since the proof was passed
to the server, you don't need the client hooks to run the commands
automatically for you. This gives the user the flexibility to run the
tests (or whatever) on their schedule but still allows the admin to
require certain standards for commited code.
> > > # 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.
>
> This is correct. But with the server-hook the only information you can
> include is information you can get out of the repo. And that is
> _exactly_ what I am missing. Please read ahead.
>
>
> After a close look at my scripts I start to notice what I am _really_
> missing. You are right: I don't really need the client side
> hooks. Most of the quirks those scripts do are to get around cvs
> design issues and are not needed anymore with svn. The only thing that
> remains is to mantain additional, independent change-logs. Let me explain
> this a little bit closer:
>
> Additionally to the log-messages (which are primarily for developers)
> we maintain additional change-logs for testers and for customers. Those
> logs don't go in that detail as the logs for developers, because the
> testers/customers start asking silly questions if you give them too
> much information (not that askig questions were a bad thing. But
> answering them takes a lot of time ;-)
>
> The structure of those logs is somewhat different. Usually there is
> one entry for every _released_ revision which contains all the changes
> made in previos revisions.
>
> To help people to maintain those logs, a perl script is used for
> checkin. This script calls an editor to get the changelog-entries,
> does some kludges to integrate them into the main changelog file and
> calls "cvs ci"/"cvs tag"/"cvs tag -b"/etc/pp.
>
> The thing I am really missing is a way to get (via an editor,
> templates would be nice) additional informations (which will not be
> checked in) from the committer and pass them through to the
> server-hooks.
We used commit templates (with server-side enforcement) with CVS.
This included bug numbers and user-visible chagnes and so on. The
enforcement was through the CVS server commit hook. Subversion should
definitely include this capability if it doesn't have it yet.
Chris
--
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 Mon May 27 00:00:12 2002