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

request for discussion: repos hook system

From: <kfogel_at_collab.net>
Date: 2001-07-21 00:10:37 CEST

We are closing in on self-hosting now, and it's time to write a hook
system for the repository; would love comments & thoughts.

In order to give this discussion some shape, let's agree that the hook
system has to make possible at least the following:

   1. Commit emails
         Must give date, author, dirs and files changed, and
         information about the changes (change summaries and/or diffs)

   2. Pre-commit guards based on content
         Examine what is about to be committed, and prevent or allow
         the commit based on that.

   3. Write authorization (i.e., pre-commit guards based on identity)
         Examine who is attempting to change what, and prevent or
         allow the commit accordingly. Just to be clear, this is not
         the question "What should our auth schema be?". Subversion's
         hook system should allow a site to implement any schema
         desired. [Same with (4) below.]

   4. Read authorization
         Examine who is attempting to read what, and prevent or allow
         the access accordingly.

By the way, I'm not saying that we must do authorization this way when
Subversion self-hosts (we may, but there are also proposals to get it
all for free from Apache; we'll have to see). The point is merely
that a thorough hook interface should support this kind of thing.

There's a somewhat hand-wavish proposal in notes/alpha-checklist.txt:

> Independent library (libsvn_repos), which fs callers must call
> into. All cooperative callers of libsvn_fs (mod_dav_svn,
> ra_local) will call pre/post hooks. The interfaces in the hook
> layer will very similar to those in svn_fs.h.
>
> ANSWER: gstein proposed that in the case of pre and post-commit
> hooks, we fire off a subprocess and pass it the transaction
> ID.
>
> Hooks are all going to be provided in the libsvn_repos
> library. Configuration files are not going to *have* to be
> in the repository. They will sit on the server *near* the
> repository, and users *can* put them in the repository.

This is fine as far as it goes, but there are a lot of paths between
that and having people be able to write separate scripts, the way you
can do with CVSROOT/*info. Any thoughts on the best/quickest paths to
take?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006

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