Do multiple svnserve instances collide?

[Gabor Maroti <ma...@gmail.com>]

Hi All,

My intention is to set up a Subversion repository for a couple of
users working at different desktops (btw in a Windows environment).
Due to company policy, I cannot launch Apache or svnserve on a server
machine.

I thought of the following.  The repo is on a network drive, each user
runs svnserve on his/her own desktop to access the repo via "svn://".
(Then each user can run svnserve as "SvnUser" who has the exclusive
rights for the repo.)  Is this a reasonable idea?  What I'm afraid of
is that simultaneous check-ins might lead to a broken repo.

An alternative would be "file://" access; that's quite awkward because
of the user rights.  On the other hand, if simultaneous svnserve
copies may conflict with each other than simultaneous "file://" should
not be safe, either...

I would appreciate any kind of hint and help.
Gabor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Do multiple svnserve instances collide?

[Troy Curtis Jr <tr...@gmail.com>]

On 11/25/06, Gabor Maroti <ma...@gmail.com> wrote:
> Hi All,
>
> My intention is to set up a Subversion repository for a couple of
> users working at different desktops (btw in a Windows environment).
> Due to company policy, I cannot launch Apache or svnserve on a server
> machine.
>
> I thought of the following.  The repo is on a network drive, each user
> runs svnserve on his/her own desktop to access the repo via "svn://".
> (Then each user can run svnserve as "SvnUser" who has the exclusive
> rights for the repo.)  Is this a reasonable idea?  What I'm afraid of
> is that simultaneous check-ins might lead to a broken repo.
>
> An alternative would be "file://" access; that's quite awkward because
> of the user rights.  On the other hand, if simultaneous svnserve
> copies may conflict with each other than simultaneous "file://" should
> not be safe, either...
>
> I would appreciate any kind of hint and help.
> Gabor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

I believe that svnserve uses the same interface to access the
repository as a client would when accessing the repo via file://.  I
am sure there are some differences but basically svnserve is just
another client.  Given the fact that you can have someone using the
svn:// url at the same time as someone else is using the file:// url
without bad things happening, you should be able to have multiple
svnserves going.

The only caution I would give you is in what backend you are using.
You basically can't use Berkeley DB repos over a network share (well
you can, but not without risking corruption), so that means that you
should only do what you are suggesting when using the FSFS backend.

Troy
-- 
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Do multiple svnserve instances collide?

[Ryan Schmidt <su...@ryandesign.com>]

On Nov 25, 2006, at 09:22, Gabor Maroti wrote:

> My intention is to set up a Subversion repository for a couple of
> users working at different desktops (btw in a Windows environment).
> Due to company policy, I cannot launch Apache or svnserve on a server
> machine.
[snip]

Have whoever made that company policy rethink it; it is silly. Use  
svnserve (or apache) on a server machine. Give only the svnserve (or  
apache) user access to the repository files on the server disk.

The alternative is to give all users complete access to the  
repository files via a network share, as you propose. The problem  
with this is that you cannot implement any security policy, because  
it can be very simply circumvented by any user by copying the entire  
repository to their local drive and removing the security  
restrictions. Any user can also go in and delete any part of or  
corrupt the repository, since they necessarily need full access to  
the files in order to use the repository. This does not seem like a  
situation that your company should tolerate; therefore, allow the use  
of a server process which is designed to eliminate these problems.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org