Hi Marc,
Thanks for your response. By concurrent I meant 100-200 commits per
second which could be the peak load on the repository. I did some simple
tests and having concurrency issues. I hosted a repository on a NFS and
had two svnserve daemons running in two different machines. When two
concurrent commits were issued using the two different svnserve daemons,
the repository is in a weird state and doesnt allow any more commits
with an error as checksum mismatch.
Steps:
1. Create a simple svn repo on a network filesystem using FSFS
2. Start svnserve daemon on two different machines which has access to
the network file system repository
3. Checkout files from the svn repository using the two different
svnserve daemons running in different machines.
4. commit files simultaneously using the two svnserve daemons
(surprisingly both the commits resulted in the same revision number)
5. When I do update on the checkouts one of them is in an inconsistent
state and doesnt allow further commits.
Is running two svnserve daemons on a single repository is supported ? I
am doing this just to make sure that in case if having one svnserve
daemon's doesn't scale for 100-200 concurrent users per second I can
have two machines handling the commits.
thanks,
Vishnu.
Marc Haisenko wrote:
> On Friday 15 February 2008, Vishnu Venkatesan wrote:
>
>> Hi,
>> I am in the process of evaluating subversion for hosting a repository
>> of about 10,000+ files with a size of 2 GB that can change at least 10%
>> everyday.
>> Can anyone please let me know if there are any references of subversion
>> deployment with such large repository with FSFS or Berkeley DB.
>> Some of the things that I am looking for
>> 1. What would be the advantages of using one over the other (FSFS vs
>> Berkeley DB)
>> 2. Any specific limitations
>> 3. How much scalable the repository would be -- for about 100-200
>> concurrent commits
>>
>> thanks,
>> Vishnu.
>>
>
>
> I think 2GB is now considered to be small to medium size... our repository is
> 5GB, and the KDE, GNOME and GCC folks will propably laugh about such small
> repositories ;-)
>
> Look at the testimonial site:
> http://subversion.tigris.org/testimonials.html
>
> You will see that a lot of very large scale projects are listed there (KDE,
> GNOME, GCC, Python, Samba, Mono), and they're all doing fine.
>
> But on to your questions:
>
> 1.: Don't know about that... most people now prefer FSFS, it seems.
>
> 2.: Maximum revision number is (AFAIK) 2^31 - 1, so you won't run into it for
> next decades even if you commit every second. The next limitation that is of
> importance is your filesystem: I wouldn't store the repository on a FAT16 ;-)
> Choose a modern filesystem that can handle a lot of files and if you're going
> with BDB you'll propably need one that can handle file sizes >2GB. AFAIK all
> modern UNIX/Linux/Mac filesystems do, I have no idea about Windows but I
> assume NTFS does as well. If you're using FSFS you'd propably want a FS that
> can handle a lot of small files well (on Linux I'd say ReiserFS but several
> people here might disagree... I think you better take what you're comfortable
> with, as long as you don't intend to set up a repository that will be under
> EXTREME load, by which I mean several commits per second).
>
> 3.: Don't know what you mean. Do you mean 100-200 concurrent commits per
> second/minute/hour/day ? Or do you mean 100-200 people working on the same
> file(s) concurrently ?
>
> HTH,
> Marc
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-15 22:49:00 CET