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.

Solution 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.

Solution 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.

Solution 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.

Solution 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.

Solution 5

Personally I prefer each project in it's own repository

View more solutions

Comments

[Nicholas Riley]

While Subversion might be a bit slow, I've certainly not noticed it slow down with the kinds of load a personal project would be remotely likely to inflict; the added administrative overhead of multiple repositories would be much more annoying.

[Pigsty]

If you keep your projects in separate directories in a single repository, then each project would still have its own history of commits.

[Steve Jessop]

I was going to say that, but then it occurred to me that maybe not everybody uses just local repositories for their own stuff. If you plan to set up a web interface, and access restrictions, and so on, for each repository, then it's more than no work. Although I imagine it's scriptable.

[Nicholas Riley]

Yeah, that's what I meant - repositories that aren't network accessible aren't terribly useful to me as I work from at least 5 machines every day. (I realize I'm probably in the minority that way).

[Cees Timmerman]

I've noticed 1000+ revisions do cause a minute or so of processing, so it depends on how many check-ins there will be and how long the repository will be around.

[Jonny]

In my CI setup I tag builds with the revision number that is exported from the repository. It's very easy to go back and find the exact state of a project, but this requires separate repositories.

[Jason]

Very good reasoning, this should be the top answer in my opinion.