Now that we're looking at Subversion and Mercurial, I'd like to
resume the discussion we were having about hooks. (Apologies to all
for dropping this topic for a bit.) Steve did some preliminary hooks
in Perl, but we need to reset that due to 2 below.
Long term constraints:
1. Hooks programs should share common functions whether targetted at
Subversion or Mercurial workspaces. Issuing mail, querying a
formatted repository file (or the MySQL database directly), and
other typical functions need to be the same implementation for
both types of repository.
2. Containing language explosion. Because we've got two major
components using Python (Mailman and Mercurial), and because
there's a Python interface to SVN, I'd like the hooks to be
written in Python.
Short term constraints:
3. Changing the database schema for version 1.0 isn't okay. We're
doing the web portal development for repository hosting based on
the console and hosting specifications. If a hook requires new
data in the schema, it will have to wait for a subsequent
delivery.
(However, the source for the web portal and the SCM host will be
available at that point, so that may not be an enormous delay.)
4. Changing the web portal for version 1.0 is discouraged. If
there's a way to manage the hooks configuration from the client
side (or mostly from the client side), that should be preferred.
When I draw the outcome of these constraints, I get something like
this for a Subversion precommit hook:
SVN hook initialization
Global repository lock sub-hook
Per-user, per-branch permissions check sub-hook
SVN hook finishes
while an ON Mercurial equivalent is spread across the prechangegroup
hook:
Hg hook initialization
Global repository lock sub-hook
Hg hook finishes
and the pretxnchangegroup hook:
Hg hook initialization
Approved RTI check sub-hook
Hg hook finishes
(which assumes we have something analogous to an RTI).
Comments?
- Stephen
[] One distinction specific to SVN is that the postcommit hook will need
to inform the system to pull an updated child, since SVN doesn't
store a clear file HEAD in its server representation. (That is to
say, an exact analog of commitinfo requires some translation.)
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
_______________________________________________
tools-discuss mailing list
[email protected]
