Subversion Best Practices

Note: This is not a tutorial. This information assumes that you already know Subversion.

Repository layout

There are serveral recommended layouts depending on your repository usage. Here are the most common.

1) You use your repository for just one software project. On the root of your repository, you should have:

branches/
tags/
trunk/

2) You use your repository for several software projects which are heavily interconnected. On the root of your repository, you should have:

branches/
   project1ExampleBranch/
   project3ExampleBranch/
tags/
   project1ExampleTag/
   project2ExampleTag/
trunk/
   project1/
   project2/
   project3/

3) You use your repository for several software projects which are not interconnected. On the root of your repository, you should have:

project1/
   branches/
   tags/
   trunk/
project2/
   branches/
   tags/
   trunk/
project3/
   branches/
   tags/
   trunk/

The Branch-When-Needed system

(This is the system used by the Subversion project.)

  1. Users commit their day-to-day work on /trunk. /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
  2. A single commit (changeset) must not be so large so as to discourage peer-review.
  3. If rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.

Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

General recommendations

  • Always write a descriptive log message when you commit something, even if it is a little minor change (you can actually specify this in the log message itself).
  • Always check merges. Be careful of automatic merging.
  • Use repository hooks to ensure internal software policies. (no passwords in code, case insensitivity, etc.)
  • Use reserved checkouts (locking) for binary files and other file types that can not be merged.

Branch and tags recommendations

  • Each release is on a branch and switch working copies to it when working (svn switch command).
    • If so, trunk must be stable always. It must pass the test bench.
  • Release points are tagged.
  • Never commit to tags, that is what branches are for.
  • If you are no longer going to commit to a branch, delete it!
  • If you, for any reason, want a read only branch, you are mistaken, what you really want is a tag. smile
  • Branch merges are always done back to the trunk.

Bug tracking usage recommendations

  • Make your bug tracking software automatically update tickets when commiting. Ex: Trac

Bibliography

Suggestions: If you have suggestions, please send me an email to david.horat@cernNOSPAMPLEASE.ch

-- DavidHorat

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2009-08-05 - DavidHorat
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    ITGT All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback