-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arlie Davis wrote:
...
> Request for Comments
> --------------------
> 
> If you are interested in this feature, please read through 
> this proposal, and provide your (constructive) comments,
> either to the SVN development list (dev@subversion.tigris.org)
> or privately to me, at adavis@stonestreetone.com.
Any outcome from private comments is going to show up here eventually,
so I'd not encourage them.
> Spec Change Log
> ---------------
> 
> 0.0 - 2/20/2006
>    Posted first version to dev list
>    
> 0.1 - 2/21/2006
>    Incorporated list feedback
>    Changed parameters for --create-service
>    Added new --update-service
>    Added new --list-service
You are most welcome to exercise this level of formality if you wish,
but it is not a requirement.
> Command-line Changes
> --------------------
> 
> svnserve would be modified to support these new command-line
> parameters:
> 
> 	--service
...
> 	--create-service <name> [parameters]
I think it might make most sense for other options to not be considered
parameters of --create-service, rather, let them all be in any order.
svnserve can easily know which parameters are relevant at
service-installation time, and which need to be saved for
service-invocation time.
>       --service-start [auto|manual]
>          Specifies whether the service should automatically be
>          started when the system boots.  "auto" means that the
>          service should be started.  "manual" means that the
>          service should not be started, but can be started
>          later by an administrator.  This parameter is optional;
>          if omitted, the "auto" value is the default.
If the parameter is omitted, the user is confused. Therefore, the
parameter should be required. Besides, I don't think that the svn/apr
options system supports optional parameters to switches.
>       --root <root>
>       --listen-host <host>
>       --listen-port <port>
No reason to respecify these, since they already exist. But, whilst we
are listing this category, don't forget --read-only too.
>    --update-service <name> [create-parameters] [--restart]
Nice bonus feature.
I'd be inclined to omit the --restart option and feature entirely
though, because it seems weird to include this limited stop/start
control, yet not include generic stop/start control.
It's trivially accomplishable with:
 svnserve --update-service svn1 ; net stop svn1; net start svn1
anyway.
>    --list-service [--config] [--csv | --tsv]
>    
>       Shows a list of the installed SVN services on the local
>       machine.  For each installed SVN service, the command
>       displays the service name, current status of the service
>       (stopped, running, starting, stopping, etc.), and if the
>       service is running, shows the process ID.
> 
>       If the --config parameter is specified, then this command
>       will also display the configuration for each service.  This
>       includes the service name (the name originally provided
>       to --create-service), the root path, the listen port, and 
>       the listen host of each service.
>       
>       If the --csv option is specified, then the fields are
>       printed as comma-separated values.  If the --tsv option
>       is specified, then the fields are printed as tab-separated
>       values.  This facilitates the use of this command in
>       scripts.
Wow, that's a lot of extra functionality, and I'm starting to worry
slightly about feature overload.
I'm also very hesitant to add a --config option that only makes sense
when in the presence of --list-service.
Of course, that's hardly anything new, since the same applies to
- --listen-host|port only applying with --daemon or --listen-once.
However, with the number of options growing significantly, it's getting
more of a problem.
To deal with this, it might be appropriate to restructure svnserve's
command line parsing to use the subcommand paradigm like other svn
commands do. For example:
Global: --help --version
svnserve daemon --listen-host --listen-port --foreground \
                --listen-once --pid-file --read-only --root
svnserve inetd --read-only --root
svnserve tunnel --tunnel-user --read-only --root
svnserve service ...
svnserve install-service ...
svnserve delete-service ...
...
Of course, this is a larger issue, and it wouldn't be fair to block the
initial windows-service work on it. To this end, I suggest omitting
- --list-service from version 1 of the windows-service work, as no other
part of the work depends upon it.
>    --delete-service <name> --root <root>
> 
>       Deletes a service that was created using --create-srevice.
>       As a safe-guard, the user must provide the same root path
>       that was specified during --create-service, in order to
>       insure that the correct service instance is being deleted.
I do not believe this safeguard is worthwhile. Please remove it.
> Configuration Data
> ------------------
> 
> svnserve would be modified to store and read startup parameters
> in the registry key associated with the service. 
I oppose any special registry storage of parameters unless there is a
very good reason they cannot simply be included in the command line the
Service Manager uses to invoke svnserve.
> Installer GUI
> -------------
> 
> In addition to the command-line support for creating and managing
> service instances, I will contribute a GUI app for doing the same 
> thing.
I am uncertain that a GUI app for this is worthwhile, and recommend it
be handled as a separate follow-up project, if at all.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFD+5VGfFNSmcDyxYARApqlAJ9hloDsouxfQ78IDIKnYYbKqjFMaACghGo/
fr9ijpB01ZEKrHL3J3ouBAU=
=53up
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 21 23:34:34 2006