RFC: User Defined Commands

<caveat>I acknowledge that this suggested enhancement is post 1.0; unless
someone finds the idea so appealing that they want to have it now. I am not in
a position to do the patch myself (too many other irons in the fire).

I am mostly looking for gut reactions to my formally adding a enhancement
request to the database. I would flesh out my proposal prior to doing so, in
that case.

I am more interested in discussion the possible public interfaces than the
specifics of the particular script I will probably wind up writing anyway.
Please don't focus on how many things I have missed in the subsequent
description of my use case (and I _know_ that is half-baked at the moment ;~),
but rather on the proposal itself.
</caveat>

<proposal>
It occurred to me that it would be very useful for a site administrator to have
scripts available to act as extensions to the existing subcommands. These would
be installed in the repository by the administrator and could possibly run
server side. These scripts would be similar to hooks (and in fact I know could
use the pre/post revprop scripts to do most of what I want). Mostly it is the
idea that there be the possibility of user initiated hooks outside of the scope
of the existing 5 hooks.
</proposal>

<use case>
For example, I want to write a script called "release" which would do a number
of things for me any time I want to post a Perl module to CPAN. It would be
useful if this were run as if it were a subversion subcommand, e.g.

        $ svn user release My::Module

where the script "release" would be passed the svn url of My::Module (and/or
some other appropriate parameters). The script would then be required to use
the bindings or command line utilities to perform whatever alterations would be
required.

In my case, "release" would locate the master version for the project (an
attribute probably) and perform a 'svn diff' of the WC versus the tag of the
current release. Obviously the repository layout would need to be standardized
so that this could happen. This may be a recursive search, for modules with
submodules having their own release version/schedule.

If the WC version is different from the tag version, then the module version
string would be incremented (in a user definable fashion), the module test suite
optionally run (to make sure no dependecies exist), and optionally the Changes
file automatically created from the 'svn log' of the module. Iff this succeeds,
then commit the new version of the module and tag it (optionally generating the
tar file and checking that in as well).
</use case>

I know that I don't _need_ to do it this way, and when I develop my "release"
script I can easily test it without it being integrated into subversion in this
fashion. I can just see that it would be much better if it were tightly
integrated into subversion.

For example, 10 developers could have write privileges to a repository but only
one would have release privileges. Currently, this is handled by social
contract alone; with a site specific extension to subversion, this could be
enforced by limiting access to the release script via the Apache.

A further use would be to enforce project guidelines prior to a release. For
example, a release would be prohibited if no changes had been made to project
documentation or history files. More than once, I have found releases where the
only notation of change is in the code itself. This is another social issue, in
that good practice would mandate this, but there is a time and place for placing
stronger constraints on releases.

This could also be used to pre-stage a release, so that a group of developers
could smoke a release prior to making it official.

Another example of it being more useful integrated would be the issue of
testing. If, for example, there was some large dataset which was required for
full scope testing, being able to run the full test suite on the server would be
a strong advantage. In this case, the developer could check in a change (having
done all of the simple tests locally), then trigger an asynchronous release via
ra_dav. The server would test all possible variants overnight (think smoke
test), then e-mail the committer the log of the test run, plus the tar'd module
if no errors were found.

What do you think?

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org