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
> 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
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:33 2006