Best practice for creating subversion repositories?

Question

Our team (5-10 developers) plans to adopt Subversion for our .NET (Visual Studio) projects/solutions (VisualSVN Server, TortoiseSVN / VisualSVN).

What is the best way to organize a new repository tree? Is it okay to use one big repository or is it better to create different repositories for every solution / product line etc.?

Our projects can be categorized this way (example):

• Main Product Line
  • Main Web App
    • Library 1
    • Library 2
    • ...
  • Windows Client
  • Another Windows Client
  • Windows Service
• Tools
  • Tool A
  • Tool B
• Product Line 2
  • Software 1
  • Software 2
• Product Line 3
  • App 1
  • App 2

Strumpet

Answer 1

Generally, you want to use a separate repository in any case where you are expecting different access permissions (i.e. some developers should have commit access to one project, but not another, or one project has a public read-only anonymous interface but another doesn't).

You want everything in one repository if you don't need that level of access control, especially if you need to be able to copy or move files between projects (i.e. projects might share code).

Put your trunk/tags/branch split at whatever level corresponds to a chunk of code you might release as a single package (i.e. think of where you would tag). This isn't critical to get right at first, since these no different internally from any other folder, so you can just move things around later, though of course it's neater not to have that problem.

Sunbonnet

"projects might share code", that is why you have vendor branches. Even thou it means that you are your own vendor... ;-) However it solves the "one to many"/"1..n" relation that you often have with shared code. – Crumhorn

Answer 2

My source of inspiration:

• Version Control with Subversion
• Subversion Repository Layout
• Single Repository or Many
• Multiple Subversion repositories

Phlogopite

Answer 3

• SVN managment standpoint I prefer 1 repository.
• Programmer standpoint I prefer 1 repository.
• Server Administrator I prefer 1 repostitory.
• Security standpoint it is preferrable not to put all of your eggs in one basket.

Your repository structure will be somewhat unique to your business, and it's products. We keep ours in one repository. Our structure somewhat like this.

• /
  • Projects
    • Project Name
      • trunk
      • branches
      • tags
  • Documentation
    • Project 1
  • Shared Libraries
    • Super string class
  • Small utilities
    • vim enhancement X

Dou

I disagree about the security standpoint. If you're not adminning one SVN Repo/SVN Server correctly, you're not going to be adminning 3 correctly. And with 3 servers it's much easier to make a ommission in configuration on the server or network. – Herrera

I see you point. Bad security management is minimized. I was thinking more along the lines of things like repo may be separated by on different servers so if server A is compromised repo's on server B are still secure. Also passwords; 1 password gets you access to all company source, and docs. – Dou

Answer 4

We use one big repository, and just have everything structured in subfolders (/project1, /project2 etc) and that seems to work fine.

The Apache project has a huge svn repository and it seems to do OK for them! :)

In terms of organisation, the structure you gave looks quite reasonable. I think anything goes, pretty much, so long as it's rational (i.e. mixing up every single tool with every single project is probably a bad idea etc). So pick something which works for you (tools/, projects/ etc). Subversion has pretty good support for moving things around in the repository, too, so you can always change if necessary.

Cienfuegos

Answer 5

We have a single repo that's structured like that. Anything that is worked on by more than a few people and/or in active development is set up with trunk/ tags/ branch/ under the main folder.

We would probably put those the trunk-tags-branch folderset under every subfolder you listed, except maybe a library or two that aren't in active development.

Herrera

Yeah, using trunk / tags / branches seems to be a best practice - we use it at my workplace too. – Cienfuegos

Answer 6

Try to keep regularly accessed material (code, scripts) separate from the 'write-once and commit to backup' stuff. Having to checkout/update thousands of jpegs just to change a few lines of code gets dull very quickly.

Bicentenary

Answer 7

We have separate repos for each project; but the main reason is for access reasons plus if the customer wants a copy of their source we can give it to them with history without too much fuss. If you look at the config files in conf it's not that hard to have a universal config file that will work for all of your projects. We do it like this:

[general]
anon-access = none
auth-access = write
password-db = ../../conf/passwd
authz-db = ../../conf/authz

authz:

[groups]
AOS = nathan,mark

[AOS:/]
@AOS = rw
frew = rw

and then of course passwd:

[users]
frew = password
nathan = awesome
mark = station

Unific

Answer 8

I am using one repository and many projects as below:

Projects
   Project Name
      trunk
      branches
      tags

My only concern is the backup and restore. The SVN backup is done at the repository level, so the restore will restore all projects instead of just one.

Jirong

Stroller