[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Repository: naturally a single- or multi-Project versioning storage?

From: Ryan Schmidt <subversion-2012a_at_ryandesign.com>
Date: Thu, 1 Mar 2012 11:24:38 -0600

On Mar 1, 2012, at 10:47, Pietro Moras wrote:

> Having to develop two distinct, un-related Projects, I wonder whether it is sensible to store them both into a unique Subversion Repository, or it is natural to create two distinct Repositories, each one dedicated to a unique Project.
>
> In other words, a Subversion Repository is naturally meant for more than one, unrelated, independently versioned project, or not?

You can do it either way. And whether you choose a single repository or multiple repositories today, you can change your mind later: with some effort, a repository can be split, or multiple repositories can be combined.

I myself started with a single repository for all of my programming projects, but in recent years have switched to making a new repository for each project. I find this to be more flexible. For example years ago I wanted to open-source one of my private projects and put it on Google Code; before I could do so, I had to disentangle it from all the other projects in my monolithic repository, using svnadmin dump and svndumpfilter. It would have been easier if it had been in its own repository already. And if a project becomes obsolete, you can move its repository to archive media without impacting your other projects. You'll note this is also how various hosting companies do it: if you make a project on SourceForge or Google Code, you get a new repository just for that project; you don't share a repository containing other people's code.

However, the Apache Foundation, which hosts Subversion's repository, uses a single repository for all projects, and that works too. So it's up to you.
Received on 2012-03-01 18:25:17 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.