CHAPTER 17 ■ VERSION CONTROL WITH SUBVERSION
I can now acquire this snapshot at anytime with the checkout command. However, a tag is not usually
intended to form the basis of parallel development (see the section on branches later in this chapter for
that). You may, however, want to export a tagged copy, ready for packaging.
Exporting a Project
As you have seen, a checked-out project includes administrative directories (named .svn). Depending
upon how you have configured your build and packaging tools these may clutter up an official release of
your project. Subversion provides the export subcommand to generate clean release versions of your
codebase.
$ svn export svn+ssh://localhost/var/local/svn/megaquiz/tags/megaquiz-release1.0.0 \
megaquiz1.0.0
A megaquiz1.0.0
A megaquiz1.0.0/quizobjects
A megaquiz1.0.0/quizobjects/User.php
A megaquiz1.0.0/quiztools
A megaquiz1.0.0/quiztools/AccessManager.php
A megaquiz1.0.0/main.php
A megaquiz1.0.0/command
A megaquiz1.0.0/command/Command.php
A megaquiz1.0.0/command/CommandContext.php
A megaquiz1.0.0/command/FeedbackCommand.php
A megaquiz1.0.0/command/LoginCommand.php
Exported revision 9.The first argument to export specifies the source. In this case, the tag I created
in the last section. The second argument specifies a destination directory which Subversion will create if
necessary.
Branching a Project
Now that my project has been released, I can pack it away and wander off to do something new, right?
After all, it was so elegantly written that bugs are an impossibility and so thoroughly specified that no
user could possibly require any new features!
Meanwhile, back in the real world, I must continue to work with the codebase on at least two levels.
Bug reports should be trickling in right about now, and the wish list for version 1.2.0 swelling with
demands for fantastic new features. How do I reconcile these forces? I need to fix the bugs as they are
reported, and I need to push on with primary development. I could fix the bugs as part of development
and release in one go when the next version is stable. But then users may have a long wait before they
see any problems addressed. This is plainly unacceptable. On the other hand, I could release as I go.
Here, I risk shipping broken code. Clearly, I need two strands to my development.
Subversion allows you to maintain parallel strands of development in a project. I can continue
working on as before in the trunk. It is here that I add new and experimental code. Let’s use a particular
file, command/FeedbackCommand.php, as an example.
class FeedbackCommand extends Command {
function execute( CommandContext $context ) {
// new and risky development
// goes here