Should I store all projects in one repository or multiple?

Question

I am currently using TortoiseSVN to manage a couple of the projects that I have on the go at the moment. When I first moved everything into source control I wasn't really sure how everything should be laid out so I ended up putting each project into its own repository.

I was wondering would it be a good idea for me just to move them all into one big repository and have them split into project folders? What does everyone else do?

At the moment none of them share common code but they may in the future. Would it make it easier to manage if they where all together.

Thanks.

Answer 1

Depends to an extent what you mean by "project".

I have a general local repository containing random bits of stuff that I write (including my website, since it's small). A single-user local SVN repository is not going to suffer noticeable performance issues until you've spent a lot of years typing. By which time SVN will be faster anyway. So I've yet to regret having thrown everything in one repository, even though some of the stuff in there is completely unrelated other than that I wrote it all.

If a "project" means "an assignment from class", or "the scripts I use to drive my TiVo", or "my progress in learning a new language", then creating a repos per project seems a bit unnecessary to me. Then again, it doesn't cost anything either. So I guess I'd say don't change what you're doing. Unless you really want the experience of re-organising repositories, in which case do change what you're doing :-)

However, if by "project" you mean a 'real' software project, with public access to the repository, then I think separate repos per project is what makes sense: partly because it divides things cleanly and each project scales independently, but also because it's what people will expect to see.

Sharing code between separate repositories is less of an issue than you might think, since svn has the rather lovely "svn:externals" feature. This lets you point a directory of your repository at a directory in another repository, and check that stuff out automatically along with your stuff. See, as always, the SVN book for details.

Answer 2

I would store them in the same repository. It's kind of neater. Plus why would it matter for continuous integration and such - you can always pull a specific folder from the repository.

It's also easier to administer - accounts to one repository, access logs of one repository etc.

Answer 3

My rule of thumb is to consolidate things that are delivered together. In other words, if you might deliver project X and project Y separately, then put them in separate repos.

Yes, sometimes this means you have a huge repo for a project that contains a huge number of components, but people can operate on sub-trees of a repo and this forces them to think of the "whole project" when they commit changes to the repo.

Answer 4

I would absolutely keep each project in its own repository, separate from all others. This will give each project its own history of commits. Rollbacks on one project will not affect other projects.

Answer 5

Personally I prefer each project in it's own repository

Answer 6

If you work with a lot of other people you might consider whether everyone needs the same level of access to every project. I think it is easier to give access rights per person if you put each project in a separate repository. ~~~

Answer 7

If you're going with a separate repository for each project, you might use the External tag to refer to other repositories -thus share code.

Answer 8

If your projects are independent, it's fine to keep them in separate repositories. If they share components, then put them together.

Answer 9

As long as each project has /trunk /tags and /branches you're good. Proper continuous integration is the criterion here.

Answer 10

Yes, put everything in source control.

If you're using SVN, keep projects in their own repository - svn is slow, and gets slower.

Answer 11

For Subversion, I'd suggest putting everything in the same repository; the administrative overhead of setting up a new repository is too high to make it a no-brainer, so you're more likely not to version something and regret it later. Subversion provides plenty of fine-grained access controls if you need to restrict access to a portion of your repository.

As I begin to migrate my projects to Mercurial, however, I've switched to creating a repository per project, because it just takes a "hg init" to create a new one in place, and I can use the hg forest extension to easily perform operations on nested repositories. Subversion has svn:externals, which are somewhat similar, but require more administrative overhead.