SVN Repository Layout Planning: Single-Project vs Multi-Project Trade-offs

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.

Originally published on 2010-07-22; fully revised and updated.

Source article: SVN pros and cons and repository layout.

Two common SVN repository layout models

In practice, most teams choose one of these layouts:

• Single-project layout: one repository per project.
• Multi-project layout: multiple projects inside one repository, each usually with its own trunk, branches, and tags directories.

Single-project layout: one repository per project

Advantages

• Revision numbers are isolated per project repository.
• Codebases are naturally separated.
• Security boundaries are easier to isolate at repository level.

Trade-offs

• Cross-project sharing and merge workflows are less convenient.
• Users and automation may need to track multiple repository URLs.
• Backup, hooks, and administration may be repeated across many repositories.

Multi-project layout: several projects in one repository

Advantages

• Easier coordination and movement of code between projects.
• One primary repository URL for teams and tooling.
• Centralized maintenance of repository-level operations.

Trade-offs

• Revision numbers span the entire repository across projects.
• Permission design can become more complex when teams need strict separation.

Single vs multi-project comparison

Repository planning decision flow

Use this quick flow to decide which layout should be your default.

flowchart TD
    A[Start repository planning] --> B{Need strict project isolation}
    B -- yes --> C[Choose single project per repository]
    B -- no --> D{Need frequent cross project sharing}
    D -- yes --> E[Choose multi project repository]
    D -- no --> F{Prefer one backup and admin target}
    F -- yes --> E
    F -- no --> C
    C --> G[Document naming and URL standards]
    E --> G
    G --> H[Create trunk branches tags structure]

Recommended directory structures

Use a predictable structure from day one. A common convention is trunk, branches, and tags.

# Single-project repository root
project-a/
  trunk/
  branches/
  tags/

# Multi-project repository root
engineering/
  project-a/
    trunk/
    branches/
    tags/
  project-b/
    trunk/
    branches/
    tags/Code language: PHP (php)

Example SVN setup commands

Option A: Create a single-project repository

# Create repository
svnadmin create /srv/svn/project-a

# Initialize standard directories
svn mkdir \
  file:///srv/svn/project-a/trunk \
  file:///srv/svn/project-a/branches \
  file:///srv/svn/project-a/tags \
  -m "Initialize standard layout for project-a"

# Checkout trunk
svn checkout file:///srv/svn/project-a/trunk project-aCode language: PHP (php)

Option B: Create a multi-project repository

# Create one repository for several projects
svnadmin create /srv/svn/engineering

# Create project roots
svn mkdir \
  file:///srv/svn/engineering/project-a \
  file:///srv/svn/engineering/project-b \
  -m "Create project roots"

# Initialize one project structure
svn mkdir \
  file:///srv/svn/engineering/project-a/trunk \
  file:///srv/svn/engineering/project-a/branches \
  file:///srv/svn/engineering/project-a/tags \
  -m "Initialize layout for project-a"Code language: PHP (php)

Access control considerations

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.

[groups]
project_a = alice,bob
project_b = carol,dave

[/project-a]
@project_a = rw
* =

[/project-b]
@project_b = rw
* =

Best practices and common pitfalls

• Pick a layout once, then document naming, URL conventions, and ownership.
• Standardize on trunk/branches/tags unless you have a strong reason not to.
• Avoid mixing unrelated projects in one repository without a clear access model.
• Automate backups and test restores for either layout.
• Define hook scripts and repository policies consistently so teams do not diverge over time.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.