You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Arlie Davis <ad...@stonestreetone.com> on 2006/02/20 16:31:16 UTC
Proposed work for running svnserve as a Windows service
This message is a summary of the work I propose to do to add support to
svnserve for running as a Windows Service. If you are interested in this
feature, please read through this, and provide your (constructive) comments,
either on-list or privately to me.
Summary
-------
svnserve would be modified to add support for running "natively" as a
Windows service. This allows svnserve to be managed like any other Windows
service (start / stop from "Services" management tool, see status, manage it
remotely, etc.), to be reliably started when the system boots, and to be
reliably stopped when the system shuts down.
Support will be provided for installing, enumerating, and uninstalling
instances of svnserve services. The implementation would support any number
of svnserve repositories; there will not be any limitation on the number of
installed services.
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.
--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.
--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.
Code changes
------------
svnserve/main.c
- Will add command-line parameters for installing,
enumerating, and uninstalling svnserve service instances.
- Will add command-line parameters for running the process *as*
a service. This command-line parameter will only be used
when the Win32 Service Control Manager launches the process,
not when users launch it.
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.
No other values would be stored in the registry.
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.
Doc changes
-----------
I'll document the procedures for installing, managing, and uninstalling
svnserve services.
Licensing / Intellectual Property
---------------------------------
I will contribute this work free of charge, no strings attached, in
perpetuity, blah blah blah to the Subversion project, such that the work is
compatible with the existing Subversion license.
Request for Comments
--------------------
If anyone is interested in this work, please send me feedback, either
off-list or on-list.
I want to do this work because 1) So far, I'm very pleased with Subversion,
and now use it
as my primary revision control system, and 2) I have many, many years of
experience writing
Windows services, and know that I can do this "right".
-- arlie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed work for running svnserve as a Windows service
Posted by Peter Samuelson <pe...@p12n.org>.
[Arlie Davis]
> Well, that's reasonable. But it means that the --list-services
> command will only be able to show the command line, rather than
> having knowledge of what the command line means.
True. I don't really see the problem with that, though.
> If this were the design choice, then there would need to be some
> deterministic marker between the parameters to the --create-service
> command, and the parameters to the (later) svnserve process.
I don't think it's likely that service-creation arguments will conflict
with other svnserve arguments. So it's simply a matter of taking
everything in argv that doesn't relate to service creation, and passing
it through to the command line used to start the service.
Peter
RE: Proposed work for running svnserve as a Windows service
Posted by Arlie Davis <ad...@stonestreetone.com>.
Well, that's reasonable. But it means that the --list-services command will
only be able to show the command line, rather than having knowledge of what
the command line means.
If this were the design choice, then there would need to be some
deterministic marker between the parameters to the --create-service command,
and the parameters to the (later) svnserve process. For example:
svnserve --create-service foo --service-start=manual --args --root ...
That, or the "--create-service <name>" pair of argv elements could be the
marker itself, and all parameters that relate to the --create-service
command could come before the --create-service:
svnserve --service-start=manual --create-service foo --root ...
-- arlie
-----Original Message-----
From: Peter Samuelson [mailto:peter@p12n.org]
Sent: Tuesday, February 21, 2006 12:59 PM
To: dev@subversion.tigris.org
Cc: Arlie Davis
Subject: Re: Proposed work for running svnserve as a Windows service
[Max Bowsher]
> > --create-service <name> --root <root> [--auto | --demand]
>
> Also, --root is not enough. --listen-host, --listen-port, and
> --read-only must also be service-specifiable.
In fact, just say that --create-service <name> takes *all* the rest of
argv[] (except for --automatic / --manual) and tells the service controller
to pass it to svnserve along with --service.
Better that than to try to anticipate the instance-specific options one
might want. New relevant options could be added in the future, too.
> > --delete-service <name> --root <root>
I agree with Max, since the service name is unique, you should just trust
that the admin typed the right one. If more argv[] *is* passed, though, you
probably should just check all of it against what is registered.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed work for running svnserve as a Windows service
Posted by Peter Samuelson <pe...@p12n.org>.
[Max Bowsher]
> > --create-service <name> --root <root> [--auto | --demand]
>
> Also, --root is not enough. --listen-host, --listen-port, and
> --read-only must also be service-specifiable.
In fact, just say that --create-service <name> takes *all* the rest of
argv[] (except for --automatic / --manual) and tells the service
controller to pass it to svnserve along with --service.
Better that than to try to anticipate the instance-specific options one
might want. New relevant options could be added in the future, too.
> > --delete-service <name> --root <root>
I agree with Max, since the service name is unique, you should just
trust that the admin typed the right one. If more argv[] *is* passed,
though, you probably should just check all of it against what is
registered.
Re: Proposed work for running svnserve as a Windows service
Posted by Branko Čibej <br...@xbc.nu>.
Apart from a small request to prefix all the windows-specific options
(e.g., --win-service instead of just --service), I think this is a good
proposal.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed work for running svnserve as a Windows service
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote:
> Arlie Davis wrote:
> > > 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 ?
> >
> > This is a more reliable way. I ask you to believe me that this is *less*
> > complex and more reliable, and my belief in this comes from developing,
> > testing, and supporting literally dozens of commercial-grade services.
>
> What should svnserve do if the same option is present both in the
> registry and on the command line?
>
> What functionality do you propose to offer users to help them out when
> there are conflicting options, and the one they're modifying to sort
> their problems out is not taking effect because there's another one
> overriding it?
Oops, this feature was already dropped in another thread.
Never mind.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed work for running svnserve as a Windows service
Posted by Molle Bestefich <mo...@gmail.com>.
Arlie Davis wrote:
> > 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 ?
>
> This is a more reliable way. I ask you to believe me that this is *less*
> complex and more reliable, and my belief in this comes from developing,
> testing, and supporting literally dozens of commercial-grade services.
What should svnserve do if the same option is present both in the
registry and on the command line?
What functionality do you propose to offer users to help them out when
there are conflicting options, and the one they're modifying to sort
their problems out is not taking effect because there's another one
overriding it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Proposed work for running svnserve as a Windows service
Posted by Arlie Davis <ad...@stonestreetone.com>.
>> --create-service <name> --root <root> [--auto | --demand]
[...]
>
> 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.
Agreed. "Demand" is the terminology that the Win32 API uses, but I would
rather go with "manual" since that is what users/administrators see.
> Also, --root is not enough. --listen-host, --listen-port, and
> - --read-only must also be service-specifiable.
Ok. That actually makes life a little *easier* for me in some respects. I
think I was assuming that those parameters came from the svnserve
configuration directory. I'll update my mini-spec to account for this.
>> --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.
Well, it's a safety feature. I would strongly suggest that we either
require --root or --force. --force would uninstall the service no matter
what its root is, while --root would require it. I realize that the only
thing being deleted is the Win32 service, and not the repository itself.
I'm willing to bend on this, but my preference is to require something
additional to confirm that the user has identified exactly which repository
to delete.
> 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 ?
This is a more reliable way. I ask you to believe me that this is *less*
complex and more reliable, and my belief in this comes from developing,
testing, and supporting literally dozens of commercial-grade services.
For example, one of the requirements that has been discussed is enumeration.
If these parameters are stored in a registry key (which is easy and
reliable), then the enumeration code can pick those values out of the
regisry. If, instead, those values are specified on a command-line, then
any enumeration code (or management code that would *alter* those values) is
forced to parse the command-line, pick out values, and potentially rebuild a
new command-line.
>> Installer GUI
[...]
> I'm not really convinced there is any need for a GUI to do this.
Is it a bad thing?
Max and Matthias, thanks for you comments. I'll incorporate this feedback
and post a 0.1 minispec.
-- arlie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed work for running svnserve as a Windows service
Posted by Max Bowsher <ma...@ukf.net>.
-----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