Archive for Subversion

Software development cycle with version control system

Excerpt taken from svn-book.pdf that ships with Subversion.

Most software has a typical lifecycle: code, test, release, repeat. There are two problems with this process.
First, developers need to keep writing new features while quality-assurance teams take time to test supposedly-stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bugfix without having to wait for a major new release.
Here’s where version control can help. The typical procedure looks like this:

  • Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bugfixes, and so on.
  • The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), then /trunk might be copied to /branches/1.0.
  • Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is “frozen” for final testing right before a release.
  • The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers.
  • The branch is maintained over time. While work continues on /trunk for version 2.0, bugfixes continue to be ported from /trunk to /branches/1.0. When enough bugfixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.
Advertisements

Leave a Comment

Basic guide to Subversion

1. When you port fixes from trunk or branches, make sure your log message mentions that you’re porting a
specific change from one branch to another. For example:
$ svn commit -m “integer.c: ported r344 (spelling fixes) from trunk.”

2. Merge means ‘diff-and-apply’ to local copies. Merge range of revisions, not two different trees.
$ svn commit -m “Merged my-calc-branch changes r406:480 into the trunk.”

3. Specify a reverse difference to ‘svn merge’ command to undo changes and then commit.
$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U integer.c
$ svn commit -m “Undoing change committed in r303.”

4. Resurrect deleted Items using ‘svn copy’ command and then commit.
$ svn copy –revision 807 \
http://svn.example.com/repos/calc/trunk/real.c ./real.c
$ svn commit -m “Resurrected real.c from revision 807, /calc/trunk/real.c.”

Leave a Comment