I use Subversion for my source code management needs. Every project that I work on gets put into my Subversion account at my hosting provider even if I’m the only one that will ever work on it. Using Subversion has saved me from significant loss of work on a number of occasions, so there’s no way that I’d consider not using it. I’m considering bringing my Subversion hosting in-house to a VPS that I control and have been thinking about how I want to organize my repository.

I’ve seen two different methods of organizing the repository–having a separate repository for each project, and having one, master repository with separate directory for each project. I can see advantages and disadvantages for each. Separate repositories allow individual access controls and maps directly one to one with Trac projects. One consolidated repository makes administration easier by putting everything under one repository.

So, my question to you folks, is what organization method do you prefer and why? If you’d like to share your opinions, success/failure stories or other relevant info, please feel free to leave a comment below. Thanks in advance for your input.

4 thoughts on “What’s your favorite Subversion repository organization scheme?

  1. I handle multiple clients at my job, so we do a little of both; every client has their own repository with all their projects sharing it. This way we can move each client’s repo somewhere else (or hand it over to the client) without having to hand over other clients’ data.

    We don’t currently integrate with external apps like Trac though, so if there’s a reason to split every project into its own repo, I don’t see the harm of it. it’ll help keep the individual repo sizes as small as possible, which could be useful if you need to move / split things up ever.

  2. I’ve always been a fan of one project per repository. My big fear of multiple projects in one repo is if anything goes wrong – it goes wrong for everything :)

    That said we’re using JIRA now and slowly moving to one massive repo so the pointy-hair management people can pull useful info out of JIRA/SVN.

  3. @Mark…That’s an interesting method. It’s kind of a half-way point between the two schemes that I had outline. I have several different clients each with 1-5 projects so that makes for a pretty good number of subversion repositories set up in Subclipse. With your method, I could still keep things organized but reduce the number of repositories necessary.

    @Jim I’ve been operating under 1 repo per project now too. I’d not thought about the “going wrong” part of the repo. As important as it is to have a good backup scheme, I could see where it would be even more important to have an airtight backup scheme with the one master repo scheme.

    @Michael Thanks for the recommendation. I’ll definitely check that out.

Leave a Reply

Your email address will not be published. Required fields are marked *