* Dermot McCluskey <[EMAIL PROTECTED]> [2006-04-13 06:30]:
> Stephen,
>
> First a general question: other than JDS, have any other consolidations
> indicated that they will be using SVN *long-term*?
The Companion CD consolidation expects to use SVN for the duration.
Obviously, that consolidation will be discussing its long term future,
but their C-team's intention was to host via Subversion.
> More comments in-line:
>
> > 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.
>
> I thought the sample pre- and post-commit scripts that come with the
> Subversion sources are fine. I especially like the regular expression-
> based rules for defining per user/branch/path access control. But they
> are written in Perl with a Bourne-shell wrapper. Do you really expect to
> be able to restict all scripts used with SVN and Mercurial to Python?
On the server deployments on opensolaris.org, yes. The hooks will be
restricted to a palette that deliver with updates to the SCM hosting
software.
Does one of the existing hooks do what you want with respect to
committers/branches?
> > 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.
>
> I don't understand this point. Can you give an example of
> new data in the schema that someone might want for a
> hook script?
As an easy example, if you decided to distinguish committers, so that
a class of committers ("gatekeepers") could do commits even through
the global lock, then you would need to add to the
committer-repository table a column to contain that flag.
> > SVN hook initialization
> > Global repository lock sub-hook
>
> Why is this needed? Doesn't SVN does its own locking?
> If you do need this, then you should also have an "unlock
> sub-hook" before the finish.
The intent is to make a global repository precommit/pretxnchangegroup
lock available from the administrative interface on the web portal.
> > Per-user, per-branch permissions check sub-hook
> > SVN hook finishes
>
> The important point for me is how easily can I update the
> configuration file that defines the access control rules. If it can
> be done with a COMMIT, then great. If I need to send a request to an
> administrator to be actioned in <1 business day, then I've got
> problems...
If by problems, you mean "presented with an inconvenience", then,
sure, I agree.
> > [] 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.
>
> Does this mean that some of the config files will stored in
> the repository, and commiting new versions will immediately
> impact the live server? If so - great. If not, then why do you
> need a clear file representation on the server? OpenGrok?
Well, it's more complicated than that. The environment in which the
hook runs is restricted by chroot(2); access to the clear files needs
to be defined. Depending on how many clear files you might need to
access, we can choose a way to make that subset (or the entirety)
visible.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
_______________________________________________
tools-discuss mailing list
[email protected]
