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

Re: Proposed work for running svnserve as a Windows service

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-02-21 17:40:17 CET

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arlie Davis wrote:
> Summary
> -------
...
> Support will be provided for installing, enumerating, and uninstalling
> instances of svnserve services.
...

You don't mention enumeration again below at all - though I don't think
you necessarily have to add any support for that, since the user can use
the Services control panel/MMC snapin for that purpose.

> Command-line Changes
> --------------------
>
> svnserve would be modified to support these new command-line parameters:
>
> --service
> Causes the process to run as a Windows service. Users do
> not specify this switch; this switch will only be present
> when the service is launched by the Windows Service Control
> Manager (SCM). This flag is mutually exclusive with the
> other start-mode flags, such as --inetd, --tunnel, --daemon,
> and so on. Does not require any parameters.

Yes.

> --create-service <name> --root <root> [--auto | --demand]
> Installs a new Windows Service for a given Subversion
> repository. The service is created, but is intentionally
> not started. The usual Windows procedures for starting
> and stopping the service apply ("net start <name>" and
> "net stop <name>", or using the standard Windows service
> management GUI). The --auto switch indicates that the
> service will start when the system boots, and is the
> default. The --demand switch indicates that the service
> will not automatically start when the system boots.
> This behavior can later be changed using the standard
> Windows service management UI.

I'd prefer:
  --service-startup=automatic|manual

I think it is more understandable if we use the same terminology the
Services MMC snapin uses (Automatic / Manual), and also to use one
option with a value, rather than two mutually exclusive boolean options.

Also, --root is not enough. --listen-host, --listen-port, and
- --read-only must also be service-specifiable.

> --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 don't think the --root option should be used here - it seems like
overkill, to me.

> Configuration Data
> ------------------
>
> svnserve would be modified to store and read the path to the repository
> directory in the registry key for the service. This allows svnserve to
> start without requiring the --root parameter when it is started by the
> Service Control Manager. The --root parameter could still be used to
> override the repository path.

Wait, this seems overcomplex. Why not just ask the service manager to
pass all relevant options to the svnserve command line, including --root ?

> Installer GUI
> -------------
>
> In addition to the command-line support for creating and managing
> service instances, I'll contribute a GUI app for doing the same thing.

I'm not really convinced there is any need for a GUI to do this.

> Doc changes
> -----------
>
> I'll document the procedures for installing, managing, and uninstalling
> svnserve services.

Thanks! The Subversion Book project is at http://svnbook.red-bean.com/,
if you haven't found it already.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFD+0JxfFNSmcDyxYARArewAJ4h+NGBj8PdH6fEHGss/+035qsyWgCeLc2n
oZVEfhYQkbcUYJmO9mxx9WE=
=pjw6
-----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 17:41:09 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.