Subversion Best Practices – Quick Notes

I was trying to know a bit more about Subversion folder management myself. While looking around, I found a quick and to-the-point article at Subversion Best Practices. I decided to profile a Quick-View version for my reference.

BASIC

  1. REPOSITORY: Official recommendation is to have three folders/subdirectories under the Project Root – “trunk”, “branches” and “tags”.
  2. COMMIT WISELY: Commit to reflect a single purpose.
  3. ISSUE-TRACKER: Create 2-way links between Subversion changesets and issue-tracking database.
  4. TRACK MERGES MANUALLY: Write descriptive log message that explains your merge.


WHEN, WHAT AND WHY TO BRANCH, TAG

  1. NEVER BRANCH: Small project, small team. It is easy to follow, have low barrier to entry but this is a chaotic development, might break /trunk often.
  2. ALWAYS BRANCH: Big team, Big project, dedicated management and supervision. The /trunk remains safe and is always the stable version but this will isolate coders from one another, sometimes can create conflicts and requires users to know how to use SVN effectively with extra merging lessons.
  3. BRANCH WHEN NEEDED: Perhaps the best and my favorite. The /trunk is still the stable version, branches and tags are created as and when required. However, this needs a bit more work in managing the SVN and a sync between developers. Lots of testing before merging, committing.


SO …

  • Main branch is of course the /trunk
  • Create branches at /branches/~theBranches to work separately off the main trunk and merge later.
  • Tag out releases or major versions etc at /tags/~theTags

UPDATES

1st Oct, 2007: Kalid Azad has A Visual Guide to Version Control.

  • http://www.abdulqabiz.com/blog Abdul Qabiz

    Different teams follow different ways to branch and maintain mainline (trunk)...

    There is entire arcticle on that, somewhere online..

    But it really helps understanding some of the fundamentals, either by working with different teams at same or different companies, that's how I learnt..

    -abdul

  • http://www.abdulqabiz.com/blog Abdul Qabiz

    Different teams follow different ways to branch and maintain mainline (trunk)...

    There is entire arcticle on that, somewhere online..

    But it really helps understanding some of the fundamentals, either by working with different teams at same or different companies, that's how I learnt..

    -abdul

  • Brian

    Thanks for the article, nice to get a direct summary on something that many people make horribly complicated.

  • charles

    WHEN, WHAT AND WHY #3:

    I think you are incorrect. The /trunk should be where your development is happening. It should be your "cutting edge" version of source... This is generally NOT stable.

    The only "stable" release of your software should be logged as a separate branch or tag.

    If you want to create a patch for your 'stable' release at a later point you should use a branch, as tags do not allow a commit.

  • charles

    WHEN, WHAT AND WHY #3:

    I think you are incorrect. The /trunk should be where your development is happening. It should be your "cutting edge" version of source... This is generally NOT stable.

    The only "stable" release of your software should be logged as a separate branch or tag.

    If you want to create a patch for your 'stable' release at a later point you should use a branch, as tags do not allow a commit.

  • http://brajeshwar.com Brajeshwar

    @charles

    In SVN, the trunk, branches and tags are just nomenclatures. Ever since we moved to GIT, we won't really touching SVN under any circumstances. GIT kicks real ass of SVN.

  • http://brajeshwar.com Brajeshwar

    @charles

    In SVN, the trunk, branches and tags are just nomenclatures. Ever since we moved to GIT, we won't really touching SVN under any circumstances. GIT kicks real ass of SVN.

  • kristian

    @charles
    Wise people still discuss whether or not to use a stable trunk.

    I am used to having a stable trunk and branching out when a new development cycle is started. This is merged into trunk again and tagged before release, so that all releases come from trunk. This works really well.

    If a quick fix is required one can do that in trunk and then handle possible conflicts when merging.

  • kristian

    @charles
    Wise people still discuss whether or not to use a stable trunk.

    I am used to having a stable trunk and branching out when a new development cycle is started. This is merged into trunk again and tagged before release, so that all releases come from trunk. This works really well.

    If a quick fix is required one can do that in trunk and then handle possible conflicts when merging.

  • Rob

    I totally agree with your branching, and I think the way you setup the repository in general is based on the size of the team. I found this tutorial online that has some pretty interesting comments.

    http://www.duchnik.com/tutorials/vc/svn-best-practices