You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2001/07/20 22:10:37 UTC
request for discussion: repos hook system
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
Re: request for discussion: repos hook system
Posted by David Ascher <Da...@ActiveState.com>.
kfogel@collab.net wrote:
>
> We are closing in on self-hosting now, and it's time to write a hook
> system for the repository; would love comments & thoughts.
I suggest that someone look at the design that Sendmail used for SMTP
hooks in recent versions -- the milter API:
http://www.sendmail.com/de/partner/resources/development/milter_api/
That's a C API, although we have a product which gives a Perl API.
http://aspn.activestate.com/ASPN/Reference/Products/PerlMx/lib/PerlMx.html
I suspect the milter API has very little overlap in 'details' w/ a
subversion hook API, but I get the impression from talking to the PerlMx
developers that the milter API is quite powerful, so they must have done
_something_ right =).
--david
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for discussion: repos hook system
Posted by kf...@collab.net.
Justus Pendleton <su...@ryoohki.net> writes:
> One thing I've often wanted is a hook to be able to modify the
> incoming check-ins and outgoing check-outs. One use I have forseen
> for this is coding standard formatting. The idea would be that upon
> check-in a project-wide script would normalize the code to the
> standard format. Upon checkout an individual specific script would
> reformat the code to that developer's personal preferences.
For now, we need to concentrate on matching CVS's functionality, which
is why I suggested limiting our goals to those things the CVS hook
system already provides (plus the auth stuff, which I suspect we'll
want soon).
There are a number of complexities to doing what you describe. One of
the reasons CVS keywords are so inflexible is so that they will not be
dangerous. They are known to the client, and the conventions for
expanding or not expanding them are shared among all clients. Even
so, they often cause spurious diffs, much to the annoyance of people
doing merges.
In order for stuff like this to work, the incoming and outgoing
modification schemes have to be known to the client, so it can adjust
appropriately during updates and commits. It's very dangerous to
start changing the data a person *thought* they committed, unless one
guarantees to do the inverse transformation on the way back, or
otherwise compensate. Subversion needs to transmit binary diffs back
and forth, and those diffs need to be based against the right data.
There are ways around this, of course, but it's not a two-week
project. Let's keep it simple for now. :-)
-Karl
> I guess there's really two aspects to this. One would be allowing
> individual specific scripts rather than just project-wide scripts.
> Maybe Developer A wants to know some source analysis script on his
> check-ins for personal edification. Requiring SCM admin cooperation
> often presents an insurmountable burden.
>
> The other is the modification of the checked in code. CVS actually
> already does this, it just is opaque and completely non-customizable:
> the use of RCS keyword expansion. Why limit it to that? Why not let
> the user add in whatever keywords they want. Whatever format they
> want. Maybe RCS doesn't cut it for whatever format they are using and
> want to roll their own? Maybe they want to run indent on every
> check-in.
>
> I don't know if this has been talked about much/at all but thoughts
> about how subversion would integrate with defect tracking and project
> planning software would be nice. I imagine that might require various
> hookage as well, but I'm not sure where. Maybe they are already
> covered by the triggers already available.
>
> Justus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for discussion: repos hook system
Posted by Justus Pendleton <su...@ryoohki.net>.
On Sun, Jul 22, 2001 at 06:08:09PM -0500, kfogel@collab.net wrote:
> It's one thing to have a layer which rejects a commit because its
> improperly indented. It's another to have a layer which reformats the
> commit, unbeknownst to the committer, on its way from working copy to
> repository. :-) Detection and correction are very different things.
Apparently you missed my point that RCS, CVS, and virtually every
other version control system on the planet already does this with
keyword expansion and nobody thinks that is a design defect. On the
contrary, they find it very useful. Do you not think keyword
expansion is useful? I see this as nothing more than the
generalization of a hacked implementation of a feature already extant,
wide spread, and virtually expected. Obviously opinions differ :-)
Justus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for discussion: repos hook system
Posted by kf...@collab.net.
Brian Behlendorf <br...@collab.net> writes:
> > One thing I've often wanted is a hook to be able to modify the
> > incoming check-ins and outgoing check-outs. One use I have forseen
> > for this is coding standard formatting. The idea would be that upon
> > check-in a project-wide script would normalize the code to the
> > standard format. Upon checkout an individual specific script would
> > reformat the code to that developer's personal preferences.
>
> That's the wrong layer to implement such a check - better to have a
> development policy that says "run this 'lint' program to make sure your
> code conforms to our coding standards (etc) before every commit", so that
> the developer has a chance to clean things up before it goes in. MHO.
+1
It's one thing to have a layer which rejects a commit because its
improperly indented. It's another to have a layer which reformats the
commit, unbeknownst to the committer, on its way from working copy to
repository. :-) Detection and correction are very different things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for discussion: repos hook system
Posted by Brian Behlendorf <br...@collab.net>.
On Sun, 22 Jul 2001, Justus Pendleton wrote:
> One thing I've often wanted is a hook to be able to modify the
> incoming check-ins and outgoing check-outs. One use I have forseen
> for this is coding standard formatting. The idea would be that upon
> check-in a project-wide script would normalize the code to the
> standard format. Upon checkout an individual specific script would
> reformat the code to that developer's personal preferences.
That's the wrong layer to implement such a check - better to have a
development policy that says "run this 'lint' program to make sure your
code conforms to our coding standards (etc) before every commit", so that
the developer has a chance to clean things up before it goes in. MHO.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for discussion: repos hook system
Posted by Justus Pendleton <su...@ryoohki.net>.
On Fri, Jul 20, 2001 at 05:10:37PM -0500, kfogel@collab.net wrote:
> We are closing in on self-hosting now, and it's time to write a hook
> system for the repository; would love comments & thoughts.
One thing I've often wanted is a hook to be able to modify the
incoming check-ins and outgoing check-outs. One use I have forseen
for this is coding standard formatting. The idea would be that upon
check-in a project-wide script would normalize the code to the
standard format. Upon checkout an individual specific script would
reformat the code to that developer's personal preferences.
I guess there's really two aspects to this. One would be allowing
individual specific scripts rather than just project-wide scripts.
Maybe Developer A wants to know some source analysis script on his
check-ins for personal edification. Requiring SCM admin cooperation
often presents an insurmountable burden.
The other is the modification of the checked in code. CVS actually
already does this, it just is opaque and completely non-customizable:
the use of RCS keyword expansion. Why limit it to that? Why not let
the user add in whatever keywords they want. Whatever format they
want. Maybe RCS doesn't cut it for whatever format they are using and
want to roll their own? Maybe they want to run indent on every
check-in.
I don't know if this has been talked about much/at all but thoughts
about how subversion would integrate with defect tracking and project
planning software would be nice. I imagine that might require various
hookage as well, but I'm not sure where. Maybe they are already
covered by the triggers already available.
Justus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org