On Dec 10, 2003, at 9:14 AM, John Peacock wrote:
> Ryan Hunt wrote:
>
>> I would like to know this too as it is becoming more and more
>> essential that all users of my repository use the same WC. My full
>> WC is currently 200GB and scheduled to be 5TB within 6-9 months.
>> This will be impossible to maintain more than a couple of WCs.
>
> EWRONGTOOL
>
> Working copies are intended to be limited to a single user, and not
> just for the obvious umask reasons; this is true for CVS just as much
> as it is for subversion.
>
This may be how they are intended, I don't know. However, just because
that is how they are intended to work, doesn't mean that they couldn't
be used in other ways. Just need to find a work around.
> For one thing, WC's are supposed to be on a local (not mapped) drive;
> are all of your users accessing this massive WC from a single computer
> with this WC stored locally to that machine?
>
As far as I was aware the only issue with mounted file systems was with
the repository, not the WC. If this is not the case can you identify
the issues that will arise due to accessing a WC across a network file
system?
> Secondly, I would seriously doubt that subversion will scale to 5TB
> WC's (not to mention what this means the repository must look like).
>
As far as I was aware the only limitations in this capacity were those
due to the berkeley bd. Quoted from sleepycat's online documentation:
http://www.sleepycat.com/docs/ref/am_misc/dbsizes.html
>>> "The largest database file that Berkeley DB can handle depends on
>>> the page size selected by the application. Berkeley DB stores
>>> database file page numbers as unsigned 32-bit numbers and database
>>> file page sizes as unsigned 16-bit numbers. Using the maximum
>>> database page size of 65536, this results in a maximum database file
>>> size of 248 (256 terabytes). The minimum database page size is 512
>>> bytes, which results in a minimum maximum database size of 241 (2
>>> terabytes).
>>>
>>> The largest database file Berkeley DB can support is potentially
>>> further limited if the host system does not have filesystem support
>>> for files larger than 232, including the ability to seek to absolute
>>> offsets within those files."
If there are other limitations that svn is placing on the versioned
file system I would very much like to know. If there are I will have
to rethink my strategy.
> I'm guessing you have large binary files that you are trying to
> maintain as multiple versions (correct me if I'm wrong).
You are correct.
> Unless the differences between versions are themselves significant (as
> opposed to just being able to extract any given version),
Is there any significant difference?
> there is little functionality that Subversion can provide for you
> (IMHO). I'd have to say a NAS/SAN with online snapshots is probably
> more likely to fit your actual needs.
I am not terribly familiar with SANs and the snapshot feature. Do you
have any good links that describe this process?
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 10 20:36:03 2003