SVN Repository Management

Base Setup

As a general rule, the top level of the SVN repository should be a rough list of projects/modules. 

/
  archive/
  elgg/
  management/
  trac/

The top-level directories may function as containers for closely related pieces of code. They should avoid representing a specific version. 

/
  archive/
  elgg/
  management/
    bs-admin/
    master-svn/
    master-trac/
  trac/

At the finest-grained level, code should be organized into directories trunk, tags, and branches. tags and branches are optional, depending on the state of the code (early in a project, there isn't a need for either). 

/
  archive/
  elgg/
  management/
    bs-admin/
      trunk/
    master-svn/
      trunk/
    master-trac/
      trunk/
  trac/

Importing and Upgrading From External Projects

For projects such as Elgg and Trac, we need to maintain our own patch set and customizations. The SVN Book has a chapter called "Vendor Branches" that is helpful to read through:

http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html

In general, a decent way to handle this (summarized from the URL above):

  1. Import the unpatched, original source code into trunk/.
  2. Immediately copy trunk/ to tags/VERSION where VERSION should preferably the same string used in the base project's version control system to represent this snapshot of code. Failing that, vanilla-VERSION is a good way to represent the "unflavored" version, and it will keep the unpatched versions lexically grouped.
  3. Perform a local checkout of trunk/, make local modifications, and you are on your merry way.

When NEWVERSION of the project is released and you've decided to upgrade:

  1. Checkout a copy of tags/OLDVERSION to WORKING_COPY where OLDVERSION is the latest vanilla version stored in our local repository and WORKING_COPY is just some local directory.
  2. Unpack NEWVERSION right over the top of WORKING_COPY. This upgrades the "vanilla" checkout to the latest version.
  3. Perform any cleanup of WORKING_COPY - check for conflicts to resolve, files that need svn add, and possibly files to svn rm, although that can be tough to determine.
  4. Once the upgrade works, check it back in to the repository:

svn cp WORKING_COPY <repository>/tags/NEWVERSION

where NEWVERSION should follow whatever standard was previously used for "vendor drops."

  1. Now the tricky part, because SVN's merge support is not very good. We need to apply the differences between tags/OLDVERSION and tags/NEWVERSION. First checkout trunk/ to a local WORKINGCOPY:

svn co <repository>/trunk WORKINGCOPY

and then merge the differences between OLDVERSION and NEWVERSION into WORKINGCOPY:

svn merge <repository>/tags/OLDVERSION <repository>/tags/NEWVERSION WORKINGCOPY

If all goes well, you have a clean patch that can be committed back to trunk/. If local modifications to trunk/ create conflicts with the upgrade, now is the time to resolve them.