RFC: User Defined Commands

[John Peacock <jp...@rowman.com>]

<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

Re: RFC: User Defined Commands

[Greg Hudson <gh...@MIT.EDU>]

On Sun, 2003-06-22 at 22:22, John Peacock wrote:
> 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.

This seems okay and potentially useful, but even after 1.0, I wouldn't
want to blow a command on it unless there were substantial demand for
it.

(I'll note that if you're using ra_dav as your ra access method, then
CGI provides a perfectly good mechanism for what you want.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org