[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal for svnserve as a Windows service - 0.1

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-02-21 23:33:42 CET

-----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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.