Structure of Projects in Version Control

Question

I know there are at least 10 different ways to structure project in version control. I\'m curious what some methods being used are and which ones work for you. I\'ve worked

Answer 1

I prefer fine-grained, very organized, self contained, structured repositories. There is a diagram illustrating general (ideal) approach of repository maintenance process. For example, my initial structure of repository (every project repository should have) is:

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

PA means pre-alpha A means alpha B means beta AR means alpha-release BR means beta-release RC means release candidate ST means stable

There are differences between builds and releases.

• Tags under builds folder have version number corresponding to a pattern N.x.K, where N and K are integers. Examples: 1.x.0, 5.x.1, 10.x.33
• Tags under releases folder have version number corresponding to a pattern N.M.K, where N, M and K are integers. Examples: 1.0.0, 5.3.1, 10.22.33.

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.