[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN without server?

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-10-19 17:46:09 CEST

On Oct 19, 2005, at 16:23, Reite Karl J wrote:

> I have been using TortoiseSVN and svnserve until now, and this
> works very well. Now I want to set up SVN using multiple
> repositories and with multiple users. All of the users will be on
> the same LAN.
>
> Do I need to use a server while we are on the same LAN? Or can I
> just access the repositories directly from the client?

You want to set up a server.

You presumably already have a computer that acts as file server,
where you intend to put the repository files, or hopefully at least a
computer that's on all the time. So run svnserve or Apache on that
computer and connect to the repositories that way.

Yes, you can also just put the repositories on a filesharing volume,
mount that on each computer, and use the file:/// protocol to access
it from each computer, but I'm pretty sure that's merely a great way
to shoot yourself in the foot. Anybody with sufficient privileges to
commit to the repository in this scenario necessarily also has
sufficient privileges to delete every repository file. I'm not
talking about the contents of the Subversion filesystem, I'm talking
about deleting the Subversion filesystem itself. Deleting the db
directory and so forth. And you don't want that.

file:/// is designed pretty much for people just testing out the
software, or for individual developers. As soon as you're working in
a group, you want a server.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 19 17:50:51 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.