4

I would like to know if SVN has a specified limitations of how many users and repositories it can sustain?

Thank you.

thedp
  • 323
  • 1
  • 6
  • 14
  • 2
    Are you planning to use this for something other than source code control? For example, you ask "so it can actually hold over 10 million users and 100 million repositories?" This makes it sound like you want to create a site like SourceForge that hosts many projects. If so, you would probably be spreading those projects across many servers ... 100 million repositories would take 100 TB of disk. – Beep beep Dec 30 '09 at 17:00
  • Yes, I am planning a service. So I'm doing research on how should this whole structure should be implemented with. – thedp Dec 30 '09 at 17:03
  • 1
    One point that no one else has raised, subversion does not maintain repositories or users. subversion maintains a repository of files. The only software that cares about repositories is something like viewsvn. apache or ssh handles the user stuff, not subversion. – Justin Jan 03 '10 at 20:33
  • svnserve, which is part of subversion, can also do user-based access control. Not that a lot of people will use svnserve I suspect, but it is simple. – Michael Graff Jan 08 '10 at 03:50

6 Answers6

6

There are no limitations built into Subversion. However, there are practical limits if the repositories are used a lot.

You might have a misconception that leads you to believe you do something special at install time to choose limits. You don't. When you use the 'svnadmin create /path/here' command, that is when you choose things like which back-end to use. Just use the default, it's better.

There are some things to consider though. For instance, if you have 100 million repositories all served from the same machine, the disk and/or CPU will eventually max out. I suspect the disk will first.

Michael Graff
  • 6,588
  • 1
  • 23
  • 36
2

You might want to look at the subversion testimonials page: Subversion Testimonials

I think the biggest decision you have to make is to decide whether to go for the Berkely DB backend or the FSFS backend.

gm3dmo
  • 9,632
  • 1
  • 40
  • 35
  • 2
    Regarding the backend, these days the FSFS backend is recommended since it has interesting advantages over BDB. See http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends.fsfs – Martijn Heemels Dec 30 '09 at 14:05
  • I'm still quite new to this whole thing, so I'm still learning. At what point in the SVN installation I set the backend? – thedp Dec 30 '09 at 14:11
  • fsfs is the default now. You'd do it when creating the repository with ``svnadmin create --fs-type`` – gm3dmo Dec 30 '09 at 14:21
  • Davey: So when I create without any options it's just like I do with `--fs-type`? – thedp Dec 30 '09 at 14:32
2

I don't think so, though obviously I've not tested it with a million users.. but I know a site that has - Google code uses svn and it has quite a lot of code and users.

For my part, we use active directory integration (through VisualSVN Server) so we're practically limited by ADs limitations (which I think is roughly 2 billion objects). I hold a SVN repo that is 12Gb in size, so it scales quite happily to large repositories and speed is not an issue for our repo even though its being run inside a virtual machine.

For further scalability, you can distribute the load using svnsync to create mirrors.

In short, I don't think you'll find a scalability problem with it.

gbjbaanb
  • 3,852
  • 1
  • 22
  • 27
  • 1
    +1: Google Code, VisualSVN + AD + Virtual Machine w/ 12GB Repo. I have a similar setup, with a smaller repo and performance is never an issue, but we've only got a few users. – Nate Dec 30 '09 at 17:35
1

No, it doesn't.

James Polley
  • 2,089
  • 15
  • 13
  • So it can actually hold over 10 million users and 100 million repositories? – thedp Dec 30 '09 at 14:08
  • There are no artificial (ie, licensing) restrictions preventing you from doing that. Whether it's practical is another matter, and will depend on what resources you can throw at the problem. – James Polley Dec 30 '09 at 14:21
  • It's the practical issue I'm worried about. But let's say I can allocate an endless amount of resource, will it work properly? – thedp Dec 30 '09 at 14:35
  • 1
    With endless physical resources, there is no limit to the number of users/repositories SVN will support. That said, with a modern server (quad core, 4/8gb memory, 15k rpm raid-10 drives, etc) you should not run into practical limits with 100s or even 1000s of users. – Nate Dec 30 '09 at 16:14
  • fuzzzerd: You're talking about currently active users, right? – thedp Dec 30 '09 at 17:06
  • I don't see why not. The typical useof SVN is UPDATE, work, COMMIT, so the chances of every one doing an UPDATE or a COMMIT at the same time is slim, even with 1000s of users. The bottom line is that if you have enough hardware SVN shouldn't have issues handling your user load. – Nate Dec 30 '09 at 17:32
1

You can distribute the load of heavily used repositories between servers.

You could setup

It also seems FSFS repositories can be safely shared through NFS so you could have a few SVN nodes serving the same repository through NFS. That may not scale very well though.

In extreme cases you could develop you own repository back-end like Google did.

Alex Jasmin
  • 406
  • 2
  • 6
1

Keep in mind the limitations of the system(s) managing the SVN databases. They may have limits such as the number of users or scalability issues with the number of files or directories in use. For example, Linux ext3 fs may search directories linearly, which may be an issue with millions of repos. There may be other limits such as the number of users registered on the system. Research these areas and test if necessary.

Re: testing. You could use a shell script to generate as many users as you expect to use. Then use another script to generate repos for each user with as many files as you would typically expect. Creating a comprehensive test suite is beyond the scope that can be presented here. Hope that gets you on your way.

casualcoder
  • 370
  • 1
  • 4
  • 13