views:

47

answers:

2

Would it be possible/safe to run two instances of VisualSVNServer pointing to the same repo?

I've searched around and not had any luck finding anything related specifically to this question. The only reason I ask is because we have a need to enable Windows Authentication/Integration over http, and svn authentication over https. It does not seem to be an option to run both within a single instance of VisualSVNServer.

If not, do you know of alternative solution that would allow for this?

Edit: Received the following answer from VisualSVN Support

Thanks to Subversion design, repositories are ready to be accessed by several server instances simultaneously. We haven't experimented a lot with such configuration, but I think it's possible.

Am I understand properly, that you are going to store your repositories on a network storage and run two VisualSVN Server instances on different machines?

Please take care about the server.pid. file. In the current release, this file is stored in the repositories folder. So there will be a collision between two instances of VisualSVN Server. We are going to fix this problem in the upcoming release.

You can easily relocate the server.pid to another destination by adding the following command to the "C:\Program Files\VisualSVN Server\conf\httpd-custom.conf" file:
[[
PidFile "C:/Tmp/server.pid"
]]"

A: 

I wouldn't do this because as far as I know, VisualSVN brings its own web server (Apache) and SVN binaries. I would expect locking issues when running two of each on the same repo, if it's possible at all. VisualSVN probably won't install twice at all.

This sounds like a case for separate installation of SVN and Apache and custom configuration. I can't say whether what you want is possible but I would expect it is. It's probably to be fiddly, though - VisualSVN takes away a lot of configuration hassle that you have when doing the setup manually. Questions about that would be appropriate to ask on Serverfault.com.

Apart from VisualSVN, there also are other, also commercial wrappers. Maybe one of them is more flexible in this respect.

Update: Also, check this out: Supporting Multiple Repository Access Methods from the SVN book

Pekka
Okay, I figured that much but figured it was worth a shot. Thanks Pekka.
happytime harry
Pekka, this project will be using a forced Lock-Modify-Unlock model for svn, so I do not think that should be an issue.Do you see anything wrong with setting up a separate Apache service pointed at the same repo, still using visualsvnserver for its easy windows authentication/integration?
happytime harry
@happy I don't know enough about subversion to answer this. It could well be that it's not a problem, but I wouldn't bet on it. Why not ask on the subversion mailing list? That may be the best place to get definitive info. http://subversion.apache.org/mailing-lists.html
Pekka
Answer is not correct. Subversion (and VisualSVN Server) designed to support accessing the same repository from different services and computers if repository stored on network share that have proper locking support.
Ivan Zhakov
@Ivan nice! That was the kind of feedback I had hoped for (as you seem to be one of the developers of VisualSVN, is that right?).
Pekka
@Pekka had to take Ivan's answer.. you still got my comment upvote though! Thanks for replies.
happytime harry
@Pekka Yes, I'm one of VisualSVN developers.
Ivan Zhakov
A: 

You can point two VisualSVN Server instances to the same repository if it stored on SMB share without any problems. It's typical configuration for active/active or active/passive cluster setups.

Ivan Zhakov
Nice! Just as I was hoping. Thanks Ivan.
happytime harry
See question edit above... this is doable, but current VisualSVN release stores server.pid file for each instance in repo folder, so to avoid instance collisions you must take care by relocating each instance file to a unique location
happytime harry
@happytime harry The point about server.pid is completely correct, but actually this file isn't critical for operating VisualSVN Server properly. But to make everything right way you have to tweak httpd-custom.conf to move server.pid out of network share.
Ivan Zhakov
Cool - thanks @Ivan
happytime harry