{"id":279,"date":"2026-10-13T06:51:17","date_gmt":"2026-10-13T06:51:17","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2010\/07\/22\/svn-subversion-svn-pros-and-cons-svn-repository-planning-svn-repository-layout\/"},"modified":"2026-10-13T06:51:17","modified_gmt":"2026-10-13T06:51:17","slug":"svn-subversion-svn-pros-and-cons-svn-repository-planning-svn-repository-layout","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/svn-subversion-svn-pros-and-cons-svn-repository-planning-svn-repository-layout\/","title":{"rendered":"SVN Repository Layout Planning: Single-Project vs Multi-Project Trade-offs"},"content":{"rendered":"\n

Subversion repository layout is a foundational design choice: do you keep one project per repository, or place multiple projects in one repository tree? This guide helps SVN administrators and DevOps teams evaluate both models, understand operational trade-offs, and implement a clean starting structure.<\/p>\n\n\n\n

Originally published on 2010-07-22; fully revised and updated.<\/em><\/p>\n\n\n\n

Source article: SVN pros and cons and repository layout<\/a>.<\/p>\n\n\n\n

\"SVN<\/figure>\n\n\n\n

Two common SVN repository layout models<\/h2>\n\n\n\n

In practice, most teams choose one of these layouts:<\/p>\n\n\n\n

  • Single-project layout:<\/strong> one repository per project.<\/li>
  • Multi-project layout:<\/strong> multiple projects inside one repository, each usually with its own trunk<\/em>, branches<\/em>, and tags<\/em> directories.<\/li><\/ul>\n\n\n\n

    Single-project layout: one repository per project<\/h2>\n\n\n\n

    Advantages<\/h3>\n\n\n\n
    • Revision numbers are isolated per project repository.<\/li>
    • Codebases are naturally separated.<\/li>
    • Security boundaries are easier to isolate at repository level.<\/li><\/ul>\n\n\n\n

      Trade-offs<\/h3>\n\n\n\n
      • Cross-project sharing and merge workflows are less convenient.<\/li>
      • Users and automation may need to track multiple repository URLs.<\/li>
      • Backup, hooks, and administration may be repeated across many repositories.<\/li><\/ul>\n\n\n\n

        Multi-project layout: several projects in one repository<\/h2>\n\n\n\n

        Advantages<\/h3>\n\n\n\n
        • Easier coordination and movement of code between projects.<\/li>
        • One primary repository URL for teams and tooling.<\/li>
        • Centralized maintenance of repository-level operations.<\/li><\/ul>\n\n\n\n

          Trade-offs<\/h3>\n\n\n\n
          • Revision numbers span the entire repository across projects.<\/li>
          • Permission design can become more complex when teams need strict separation.<\/li><\/ul>\n\n\n\n

            Single vs multi-project comparison<\/h2>\n\n\n\n
            Criterion<\/th>Single-project repositories<\/th>Multi-project repository<\/th><\/tr><\/thead>
            Revision numbering<\/td>Independent per project<\/td>Shared across all projects<\/td><\/tr>
            Security boundary<\/td>Strong repository-level isolation<\/td>Typically path-based isolation inside one repository<\/td><\/tr>
            Administrative overhead<\/td>Higher when many projects exist<\/td>Lower repository count, centralized admin<\/td><\/tr>
            Cross-project collaboration<\/td>Less direct<\/td>More direct inside one repository tree<\/td><\/tr>
            URL simplicity<\/td>Many project URLs<\/td>One repository URL with project subpaths<\/td><\/tr>
            Best fit<\/td>Teams needing strict isolation<\/td>Teams optimizing for central management<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

            Repository planning decision flow<\/h2>\n\n\n\n

            Use this quick flow to decide which layout should be your default.<\/p>\n\n\n\n

            \nflowchart TD\n    A[Start repository planning] --> B{Need strict project isolation}\n    B -- yes --> C[Choose single project per repository]\n    B -- no --> D{Need frequent cross project sharing}\n    D -- yes --> E[Choose multi project repository]\n    D -- no --> F{Prefer one backup and admin target}\n    F -- yes --> E\n    F -- no --> C\n    C --> G[Document naming and URL standards]\n    E --> G\n    G --> H[Create trunk branches tags structure]\n<\/pre>\n\n\n\n
            Recommended directory structures<\/h2>\n\n\n\n
            Use a predictable structure from day one. A common convention is trunk<\/em>, branches<\/em>, and tags<\/em>.<\/p>\n\n\n
            # Single-project repository root<\/span>\nproject-a\/\n  trunk\/\n  branches\/\n  tags\/\n\n# Multi-project repository root<\/span>\nengineering\/\n  project-a\/\n    trunk\/\n    branches\/\n    tags\/\n  project-b\/\n    trunk\/\n    branches\/\n    tags\/<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Example SVN setup commands<\/h2>\n\n\n\n
            Option A: Create a single-project repository<\/h3>\n\n\n
            # Create repository<\/span>\nsvnadmin create \/srv\/svn\/project-a\n\n# Initialize standard directories<\/span>\nsvn mkdir \\\n  file:\/\/\/srv\/svn\/project-a\/trunk \\<\/span>\n  file:\/\/\/srv\/svn\/project-a\/branches \\<\/span>\n  file:\/\/\/srv\/svn\/project-a\/tags \\<\/span>\n  -m \"Initialize standard layout for project-a\"<\/span>\n\n# Checkout trunk<\/span>\nsvn checkout file:\/\/\/srv\/svn\/project-a\/trunk project-a<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Option B: Create a multi-project repository<\/h3>\n\n\n
            # Create one repository for several projects<\/span>\nsvnadmin create \/srv\/svn\/engineering\n\n# Create project roots<\/span>\nsvn mkdir \\\n  file:\/\/\/srv\/svn\/engineering\/project-a \\<\/span>\n  file:\/\/\/srv\/svn\/engineering\/project-b \\<\/span>\n  -m \"Create project roots\"<\/span>\n\n# Initialize one project structure<\/span>\nsvn mkdir \\\n  file:\/\/\/srv\/svn\/engineering\/project-a\/trunk \\<\/span>\n  file:\/\/\/srv\/svn\/engineering\/project-a\/branches \\<\/span>\n  file:\/\/\/srv\/svn\/engineering\/project-a\/tags \\<\/span>\n  -m \"Initialize layout for project-a\"<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Access control considerations<\/h2>\n\n\n\n
            Single-project repositories usually align naturally with repository-level access control. In multi-project repositories, path-based authorization becomes more important. The exact section syntax can vary by server mode, but the model below shows the intent.<\/p>\n\n\n
            [groups]\nproject_a = alice,bob\nproject_b = carol,dave\n\n[\/project-a]\n@project_a = rw\n* =\n\n[\/project-b]\n@project_b = rw\n* =<\/code><\/span><\/pre>\n\n\n
            Best practices and common pitfalls<\/h2>\n\n\n\n
            • Pick a layout once, then document naming, URL conventions, and ownership.<\/li>
            • Standardize on trunk\/branches\/tags<\/em> unless you have a strong reason not to.<\/li>
            • Avoid mixing unrelated projects in one repository without a clear access model.<\/li>
            • Automate backups and test restores for either layout.<\/li>
            • Define hook scripts and repository policies consistently so teams do not diverge over time.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
              Choosing the right Subversion repository layout affects security boundaries, revision visibility, and day-to-day operations. This guide compares single-project and multi-project models with a decision flow and practical setup commands.<\/p>\n","protected":false},"author":1,"featured_media":4394,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[23],"tags":[4184,4185,4186,394,4183,395,4187,4180,4182,4181],"class_list":["post-279","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-svnsubversion","tag-advantages-of-svn","tag-disadvantages-of-svn","tag-pros-and-cons-of-subversion","tag-subversion","tag-subversion-benefits-and-drawbacks","tag-svn","tag-svn-features","tag-svn-pros-and-cons","tag-svn-repository-layout","tag-svn-repository-planning"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/279","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=279"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/279\/revisions"}],"predecessor-version":[{"id":79102,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/279\/revisions\/79102"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/4394"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=279"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=279"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}