On Fri, Jul 09, 2010 at 06:25:20AM +0000, Lorenz wrote:
> just checked, and no there is no error message.
> Instead the newly started server blocks / hides the allready running
> one.
> In my case I have one server running as a windows service, serving a
> repo from a folder on my C: drive.
> If I start a second svnserve from the command line, pointing it to a
> different folder, but listening on the the same port, that prevents
> access to the server running as a service.
> Aborting the second svnserve will allow access to repo again.
This doesn't make any sense.
I don't understand how an OS can allow a user process to break
a system service simply by binding a socket to the same port.
> So yes, there seems to be a bug in the windows version (1.6.5 by the
> way)
>
> ....
>
> After upgrading to 1.6.12 (SlikSVN) I still can start multiple servers
> using the same port, but now the server started first seems the have
> priority.
>
> ...
>
> make that: the server running as a service seems to have priority.
Can someone explain to me if this is this expected behaviour
of sockets on Windows?
What could have changed between 1.6.5 and 1.6.12 that changes
this behaviour? Maybe something unrelated to svn could cause
the service to take priority?
Thanks,
Stefan
Received on 2010-07-09 11:55:58 CEST