Separate Repositories for separate projects?

Question

OK so basically my questions is about the best practices in subversion. I am very new to subversion so dont really know too much.

so here goes my question.

I am working on 2 projects right now and also a single developer on both of them so i was wondering if its OK to put both of those projects in the same repository or make separate repositories for each of the project. I think making separate ones is much better idea, it will look clean and since they dont cost (in terms of HD space), so why worry about?

Answer 1

I used to think like that, but after a while i started discovering some code used on a project could be useful on another one (on different repositories), so now i think is best to just put everything on a single repository.

Answer 2

For a a single developer working on multiple projects that are at least somehow related to each other, it might in fact make sense to start working with one big repository, as you can easily switch and branch things.

If however one or more of the projects are likely candidates for a later separation - e.g. if a team is likely to start working on them - consider keeping projects separate from the start. That way, you have a clean version history per project. (i.e. a history not mixed with other projects' commits. You can always filter out stuff with the dump tools, but I find it way more convenient not to have to.)

Also, if one or more of your works is likely to become Open Source one day, having a clean version history is nice because social coding sites like ohloh scrutinize your commits, and add to the project's activity stats, and your profile's expertise if they detect actual commits made by you in the past. Not really important and not really telling about any hard facts, but still nice to have.

Brian Agnew makes a number of very good additional points in favour of separation in his answer.

You shouldn't have security problems when working with one big repo, as you can do path-based authentication in Subversion if people start coming on board working on the repositories.

You will, however, have to mark each commit with the project it is related to, in order to make sense out of the commit messages later.

Answer 3

I would tend towards a repository per releasable (a library, an executable, or perhaps a closely related set of libraries or executables). Why ? I can tag and branch each independently without having to worry about the structure within the repository and what state each component within that repository is in.

I can choose only to have checked out particular repositories (say, for a client executable) and simply consume the build artifacts (libraries) of other repositories. That may be useful for simple admin in teams, and focusing teams' on particular sets of code, rather than exposing them to the complete codeset used by an enterprise (I appreciate you're a solo developer, so this may not apply in your case!)

Multiple repositories are cheap to manage. It achieves separation and that's useful if (say) one repository is used to build a library or component used by other components. If that library/component has its own repository, then you can build and version it separately, and publish it for use by clients with the knowledge that they're using the build artifact and not using subcomponents of that library that they shouldn't be. I'm not sure you could easily enforce that by having everything in one repository.

Answer 4

I think it is advantageous to separate the two project if there are independent:

• You can follow the project advancement by checking the log
• if two project log are mixed, it is more difficult to find a revision (previous version of the project) you are looking for.
• [EDIT] All tools associated with subversion (project management tool like Trac for example) may not be able to manage the two project individually.

Answer 5

I keep separate repositories for each project that I do and another repository for any libraries that I've created that I intend to reuse.

The only real exception to this in my case is that all of my simple ruby scripts are kept in a single repository.

It helps make commit comments make more sense and keeping separate projects, well, separate is a good idea, because (among other things) as has been stated already, you never know what may happen to any given project.

Answer 6

I used to have all my projects in One Big Repository, but it became a little confusing: you couldn't tell what commit message went with what project without looking at the affected path names; making a commit on any project bumped up the revision number and technically made the working copies of every other unrelated project out of date (even if there were no updated files to change).

If I was working from a SVN server I wouldn't mind, but these were just repositories on my local disk. Eventually, I learned how to use svndumpfilter to separate them all into separate, per-project repositories.

If you want to share code between projects, I think the better thing to do is learn how to set up the svn:externals property. Copying stuff around within your repository is really no better than copying stuff around on disk and checking it in multiple times. You still have to do a lot of manual work if you want to propagate a file's change to all the projects that use it. svn:externals lets you reference a different repository, so you can create one repository for shared code and then another for each project.