I've found myself asking the question: should I make one repository for all the projects at this client? or should I make a separate repository for each?
Which do you normally decide?
Please list the advantages and disadvantages of either approach which lead to your decision.
EDIT: Please mark as duplicate for one of the following:
http://stackoverflow.com/questions/252459/one-svn-repository-or-many
I use a single repository for "everything" because it makes moving stuff between projects much easier - at least with SVN.
I have one large repository for the same reasons as Ken's answer:
http://stackoverflow.com/questions/252459/one-svn-repository-or-many/252491#252491
I work at a .NET development shop and we have two Visual SourceSafe repositories. One for our legacy .NET 1.1 applications and one for our newer .NET 2.0/3.0/3.5 applications.
There is only one reason that I can think of for not putting it all in one repository. And that is if you don't have access to configure the server the repository is on, and you need to restrict parts of the repository to different sets of people.
We have a centrally managed server where we can create repositories as needed, but can't change the configuration. We have a main code repository that is for internal use only, but create additional ones to collaborate with people outside the organization.
I have a repository for each project, because it keeps the version numbers independent. I followed the thinking laid out in the TortoiseSVN help section 4.1.5, "Repository Layout":
Indexing by project makes sense if the projects are not closely related and each one is checked out individually.
I'm using SVN for my own local backups in this case, so it makes sense for me.
We have one repository per TYPE of project and type of person accessing it. For example, all of our .NET projects are in a single repository, and all of our legacy applications are in a single repository. This way our .NET developers cannot accidentally hose our legacy developers (and vice versa).
I used to use one repository for all projects until it got so big that committing to the project really slowed down - this was with Subversion. If your projects are going to hold lots of data, especially binary data then I'd recommend using separate repositories. If you're primarily just storing code then a single repository is simpler to maintain.
I use several repositories -- though I admit that when it comes to organizing code, I've got a bit of OCD, and I like things to be very organized and distinct.
I manage the SCM repos at our company, and at present we've got three: one for the main projects, one for packages/libraries, and one for third-party code. If I were to do it again, I would have also made a separate repository for media files (we have lots of mp3/wav files that need to be in version control), but alas, they are under our main repo.
I think that the only strong argument for using multiple repositories (besides being obsessively organized) is that it makes it easier to deal with access rights for each of these repos, whereas depending on your SCM environment, this may not be so easy for multiple paths underneath a single repo.
I use git for almost everything. So I have a repository per Project (be it /etc, coding-projects or user-configuration files).
if you use one repository for everything it makes it harder to setup an automated build or do continues integration. Even if you don't plan to do this right now, it's not a bad idea to set it up now, this also gives you the added bonus of making it easier to manage your content.
A good rule of thumb is create a repository for every distinct group of solutions\ projects.
If you have a solutions that don't share anything, create a repository for each. Another example would be if you have a .NET 1.1 version of your application and you want to create a 2.0 versions of your application branch your code and create a separate repository for your new code, this could also be done with .NET 3.0 and .NET 3.5.