Well, I'm swayed by the argument that storing simply the raw command-line to
svnserve would isolate the service-related logic. It's unappealing for some
reasons, but I'm willing to accept this for a v1.0 of a feature.
-- arlie
-----Original Message-----
From: Mark Phippard [mailto:markp@softlanding.com]
Sent: Tuesday, February 21, 2006 4:27 PM
To: Peter Samuelson
Cc: Arlie Davis; dev@subversion.tigris.org
Subject: Re: Proposal for svnserve as a Windows service - 0.1
Peter Samuelson <peter@p12n.org> wrote on 02/21/2006 04:21:32 PM:
> [Mark Phippard]
> > I apologize in advance if this has been already discussed, but why
> > wouldn't you put the "service maintenance" options (create, update,
> > delete, list) in a separate executable, like svnservice.exe or
> > something?
>
> Probably because traditional Windows services have options to install
> and uninstall themselves, rather than having a helper binary. This is
> a convenience for distribution and installation. It may not really
> apply in subversion's case, since subversion already installs quite a
> few binaries and libraries.
It seems to me that a traditional Windows service is installed by an
InstallShield-type program. Of course the service executable itself might
be used under the covers to do this, but still I do not think there is any
real standard expectation here. I just do not see how adding all of these
command line options to svnserve is a good idea for usability. Also, note
that I am not suggesting we need to run a service manager like Apache uses,
just a separate executable that can manage creating the service.
I think the main change is just to get svnserve to run as a service without
needing a wrapper. If we wanted, we could then have the Windows installer
have options to install it, or provide manual instructions, or a separate
program etc...
Mark
____________________________________________________________________________
_
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs.
____________________________________________________________________________
_
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 22 02:11:52 2006