|
Page 3 of 5 Subversion Repository Layout Theory Subversion, with its history based on CVS, approached many things that people felt CVS did badly differently to achieve different goals. This has meant that a different approach to things has been taken to allow for certain tasks that were difficult under CVS (like renaming a file) to be easier under SVN. However one of the tasks made less clear was branching, which means that repository layout with Subversion is perhaps more important than CVS. The basic structure of a SVN repository is as follows: /
/trunk
/releases
/tags
/branches
Trunk The trunk is where the main development occurs and where most commits occur. Trunk is always the most up to date and is used to provide the next release. From trunk a version will typically be tagged and places into release. Releases Once a version of 'trunk' is said to be released, the entire trunk folder is copied into releases for that version (say 1.0). Trunk continues incrementing major version (e.g. 1.1) so that bug fixes and security fixes can be applied to the releases folder copy. From here the security or bug fix releases (perhaps even features) can be moved into tags to account for tracking of these (e.g. 1.0.1, 1.0.2). Tags Tags is typically a static (e.g. no changes after commit) location that holds each version. A typical tags directory may look like this: /1.0
/1.0.1
/1.0.2
/1.0.3
/1.5
/1.5.1
/2.0
/2.0.1
This means that a given version can be located by simply checking out the appropriate folder. This makes version rollbacks easy (svn force export a previous version) as well as moving forwards (export the new version over the top of the old version). Branches Sometimes there are large changes to the code base that might have an impact on the other developers working on the project. In this case we have branches to work on making this wide scale changes in an environment that won't impact on the rest of the repository. Because SVN has more limited support for branching, this makes merging changes back in a bit harder, however not impossible. Additionally some use a secondary branches folder for individual releases (e.g. 1.0 branch) for times when there are serious changes in the stable release.
|