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

Re: Distributed Subversion servers running off of same DB - possible?

From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net>
Date: 2005-01-18 21:48:00 CET

On Tue, Jan 18, 2005 at 02:59:48PM -0500, Greg Hudson wrote:
> On Tue, 2005-01-18 at 09:27, Luke Kenneth Casson Leighton wrote:
> > i.e. is the internal design of subversion's database locking
> > sufficiently good such that it can even extend outside of
> > running subversion on different machines with access to the same
> > databases?
>
> The BDB-based repository back end can handle multiple server processes
> on the same machine. However, BDB relies on locking through shared
> memory segments, which does not work over distributed filesystems.
>
> The FSFS repository back end can handle multiple server processes on
> different machines, each accessing the repository through a distributed
> filesystem. It requires only the basic ability to lock files; no need
> to lock byte ranges.

 ah, that's _great_ news.

 
> (I'm not sure that DFS works well enough to be an
> option,

 i am informed that DCE/DFS is about the only distributed file
 system that correctly does all POSIX file semantics, including
 byte range locking.

 [it's a pity that it's been suffocated for so long ...]

> but AFS or sufficiently modern NFS are fine.)
 
 cool. that's even better. if there existed a distributed nfs
 server... perish the thought :)

 thank you ever so much for responding, because that means i can
 recommend this as a solution to the client.

 ta,

 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 18 21:39:09 2005

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

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