[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Client side Hooks? (rethaught)

From: Josef Wolf <jw_at_raven.inka.de>
Date: 2002-05-26 22:41:46 CEST

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.

> Regardless, the server is a better place to do many of the examples
> you gave, anyway.

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

This one is not to enforce bad guys to run the tests. You can't
enforce this regardless of where the hooks are placed. This is to help
the good guys not to _forget_ to run the tests.

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

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

-- Josef Wolf -- jw@raven.inka.de --
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 26 22:43:20 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.