How do you structure your SVN repository? [closed]

We use A, because the other one didn't make sense to us. Note that a "project" with regard to SVN is not necessarily a single project, but may be several projects that belong together (i.e. what you would put into a Solution in Visual Studio). This way, you have anything related grouped together. All branches, tags and the trunk of a specific project. Makes perfect sense to me.

Grouping by branch/tag instead does not make sense to me, because the branches of different projects have nothing in common, except that they're all branches.

But in the end, people use both ways. Do what you like, but when you decided, try to stay with it :)

As an addition: We have separate repositories per customer, i.e. all projects for a customer are in the same repository. This way you can e.g. make backups of a single customer at once, or give the source code of anything the customer owns to him without fighting with SVN.

回答3:

I would suggest an option C:

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

I prefer to keep separate projects in separate repositories. Using svn:externals makes it easy to manage code library projects that are shared among two or more application projects.

回答4:

We use setting B. Beause it is easier to check out/tag multiple projects at once. In svn 1.5 it is possible via sparse checkout, but not a one-click operation. You want to use setting B, if some projects have hidden dependencies inbeetween.

回答5:

We use

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

Which I'm starting to regret. It should be flatter. This would be better.

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

Why? Products (components, finished software) last forever. Projects come and go. Last year there's just one project team creating product QUUX. Next year, that team is dispersed and one or two people maintain QUUX. Next year, there will be two big QUUX expansion projects.

Given that timeline, should QUUX appear in three project repositories? No, QUUX is independent of any particular project. It is true that the projects do have work products (documents, backlogs, etc.) that are part of getting the work done, but aren't the actual goal of the work. Hence the "projectX" repositories for that material -- stuff that no one will care about after the project is done.

I worked on one product that had three teams. Big problem with coordination of work because each project managed it's repository independently. There were inter-team releases and inter-team coordination. At then end of the day, it was supposed to one piece of software. However, as you can guess, it was three pieces of software with weird overlaps and redundancy.

回答6:

Personally I use following repository structure:

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

There is also a diagram illustrating how those directories are used. Also there is specific version numbering approach I use. It plays significant role in repository structuring. Recently I have developed training dedicated to Software Configuration Management where I describe version numbering approach and why exactly this repository structure is the best. Here are presentation slides.

There is also my answer on the question about 'Multiple SVN Repositories vs single company repository'. It might be helpful as long as you address this aspect of repository structuring in your question.