PHP Objects, Patterns and Practice (3rd edition)

CHAPTER 17 ■ VERSION CONTROL WITH SUBVERSION

Transmitting file data.

Committed revision 12.I have edited this in the meagquiz-branch1.0.0 directory. By editing and
committing here I ensure that my changes end up on the branch and not the trunk. I could tag, export
and distribute this now as a point release.
It doesn’t end there, though. Now that I have fixed the bug, I need to apply the change to my main
development strand (the trunk).

■Note To merge or not to merge? The choice is not always as straightforward as it might seem. In some cases,

for example, your bug fix may be the kind of temporary work that is supplanted by a more thorough refactoring on

the trunk, or it may no longer apply due to a change in specification. This is necessarily a judgment call. Most

teams I have worked in, however, tend to merge to the trunk where possible while keeping work on the branch to

the bare minimum. New features, for us, generally appear on the trunk and find their way quickly to users through

a “release early and often” policy.

Subversion provides the merge command for this purpose. Change your working directory to the
local destination, and invoke merge, passing it the source URL.

$ svn merge svn+ssh://localhost/var/local/svn/megaquiz/branches/megaquiz-branch1.0.0

--- Merging r12 into '.':
U command/FeedbackCommand.php

Now, when I look at the version of FeedbackCommand in the trunk, I confirm that all changes have
been merged.

function execute( CommandContext $context ) {
// new and risky development
// goes here
$msgSystem = ReceiverFactory::getMessageSystem();
$email = $context->get( 'email' );
$msg = $context->get( 'pass' );
$topic = $context->get( 'topic' );
$result = $msgSystem->dispatch( $email, $msg, $topic );
if (! $result ) {
$this->context->setError( $msgSystem->getError() );
return false;
}
$context->addParam( "user", $user );
return true;
}

The execute() method now includes both my simulated trunk development and the bugfix.