SVN Repository Structure - Why is this better?

Question

I've been told that most development shops have the following structure or at least close to this:

• Main Repository
  • Project folders underneath
  • Each Project folder has a trunk, branches, and tags folder

so:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
        ...

So why is this better or best? What happens or what heartaches have you come across if you did it another way?

Answer 1

This way of organizing the repository:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
    ...

is best when your projects aren't that connected/dependent on each other. The other way around makes it easier to version your entire project suite. So if you often release/package Project1 and Project2 together, it's best to have them share the same branch.

If, on the other hand, your project are very decoupled and have totally different teams working on them, then you wouldn't need to check them all out together most of the time, and so you could use the above method.

Answer 2

The repository structure depends on your needs. If your projects are fully separated (no dependencies between them) then this "simple" repository structure is fine. If you have dependencies in your project (eg some global "tool-libraries", shared code) you should use a different structure like:

trunk
   prj_a
   prj_b
tags
   <YOUR_TAGNAME>
       prj_a
       prj_b
branches
   <YOUR_BRANCHNAME>
     prj_a
     prj_b

or anything else which makes more sense to your process.

In the simple structure with local trunk/tags/branches it is not possible (at least in a clean way) to tag multiple projects, if you have dependencies between them.

Also the often proposed "Multi-repository" approach will not fill this gap as then you are doomed with multiple revisions or tags in multiple repositories.

The main problem is that SVN has NO support for shared ressources and tagging/branching them.

If you think about your Repository structure, you should ask yourself in what process you want to share your code libraries.

Answer 3

Trunk branches and tags are all act the same way. How you use them is up to you.

I've been using this structure for years and have yet to find a time that the structure didn't adapt to what I needed to do.

Answer 4

We keep a separate repository for each project.

While this doesn't allow you to copy and keep the version history files from one project to another, it enables you to archive a whole repository when a project is over.

Answer 5

Thanks for the Discussion here, I went through this and project-structure-for-product-with-different-versions

link2

link3

link4

I could see terminologies are confusing. Projects, Applications, to correctly correlate

Would like to repeat the above things with somewhat clear exp Lets say we do solution for a customer ABC Solution is TIcket/HelpDesk Application for ABC's Clients Queries

Lets say applicationName is OneDeskApplication. This Application consists of WebUI,Shared Libraries, Build Tools

can we design the SVN like this

XSoftware.com/ABC - Repository / trunk/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp branches/ Branch_Product_Support_1_0_0_0/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp tags/ OneDeskDocs OneDeskMasterBuild

Answer 6

At my shop, we have something like this:

RepositoryMain
  Trunk
    proj 1
    proj 2
    ..
  Dev
    Team1
      proj 1
      proj 2
    Team2
      proj 1
      proj 2
    ...

I don't know how this stacks up to most places but it seems to work pretty good

All the development teams can work separately on their own projects, merging from trunk to their project when they are beginning development/enhancement, and then merging back to trunk once they are finished.