|
Page 4 of 5 Change Management Subversion is a version control system, which means that it is implicitly implied that it handles changes within files. However since it is well suited to handling changes in files it can be used for configuration change management and examining alterations in configuration files (typically the Unix world where configuration is contained in a file as opposed to the Windows model which relies primarily on a registry). A good example of this could be the Apache directories on a web server. If these are managed by SVN we can see what changes are being made (e.g. by Webmin) to allow for rollback of settings to a last known good configuration in case of corruption of settings. Tomcat is another example of a server that utilizes file to control its configuration making it easy to version control these changes. Release Management A core usage for SVN is to provide a basis for release management. As a product is developed in trunk it will eventually reach a point where development will stop on this and the product will be released into a more maintenance mode. Whilst development of new features in trunk can occur, it may not be desirable for these to be back ported to fix a bug (or vice versa, the bug may not actually exist in the later trunk version). So for example we have a product in trunk that we have been developing and now its time to release the product. The new release version number will be '1.0' with the next release being developed in trunk called '1.1'. The following actions would occur: * The trunk is copied to the 'releases' directory with an entry with the appropriate major.minor version number (e.g. /releases/1.0) * The trunk is copied to the 'tags' directory with an entry with the appropriate major.minor.revision version number (e.g. /tags/1.0.0; optionally revision may be ignored for 1.0 release) Trunk Trunk is where the main development occurs and is continuously the most up to date version of the software. Releases Each folder contained here are under a 'maintenance' style mode where only bug fixes and security fixes are applied. Feature additions may be completed here but are typically left to the trunk branch. Since a folder here is separate to the main trunk, alterations can eb made without altering the course of the trunk or to address issues that may be a threat for the release (and hence necessitating a security fix/release) but not having an impact on trunk (e.g. that part of the code was refactored). From here branches are made for revision of the release (e.g. 1.0.1). As with trunk, a release is copied into 'tags' as well (e.g. the first security release would become /tags/1.0.1) so that in future that release can be grabbed quickly and easily. Tags Tags is the version store for every release. Ordered by version number, this is the final uneditable location of each release. Using this location as a reference, external releases can be quickly migrated forwards or back as the tags holds the changes for each release. After a release has been added to this directory it should be considered read only. Any changes happen in the relevant release directory or in trunk.
|