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

hooks for unversioned items and backups (was: Hot backup changes)

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-08-22 20:54:08 CEST

On Thu, Aug 22, 2002 at 11:55:25AM -0500, cmpilato@collab.net wrote:
>...
> I'm fine with having a growing list of hooks. For each set of
> operations that get dumped into the same hook, we have to package
> information that some script has to use to figure out which of those
> several operations actually happened. That adds complexity to the
> hooks themselves, which heightens the cost of maintainance.

While true, the set of revision properties is arbitrary. It is quite
possible that a company is setting the 'acme-status' property with the
status of a build/test cycle. Changes to that status need to be hooked just
like a log message would.

And since a log message is just another rev prop, then it should be handled
by the same prop-change hook rather than calling it out special. (if you
called it out, then you start raising questions like "if only the log
changes, then does the prop-change get called in addition to log-change?")

> I like to think of hooks as public API calls that are runtime
> resolved. I certainly wouldn't try to cram handling for changed ACLs,
> locks, and log messages into a single handle_unversioned_thing_mod()
> function.

It would seem quite fine to split the hooks by group like that: acls, props,
etc.

However, it is *very* important to note that hooks are not necessary the
"safest" way to determine changes to the FS. The hooks are implemented by
the repository layer *above* the FS. Only applications that care to
participate in running hooks, will actually do so. It is entirely possible
to write a CGI script that uses the bindings to directly munge FS props and
avoid hook scripts all together. Hell, that same script could also create
whole new revisions without the hooks getting run.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 20:50:21 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.