Game Development Reference
In-Depth Information
'
You
ll have a nice sandbox to play in and get the benefits of source control for every
source file.
SourceSafe
s branching mechanism, and I use that term loosely, makes a complete
copy of the entire source tree. That
'
s slow and fat. Most decent repositories keep
track of only the deltas from branch to branch. This approach is much faster, and it
doesn
'
t penalize you for branching the code.
Here are the branches I use and why:
'
n
Trunk:
Normal development branch
n
Sandbox:
A
“
playground
”
branch where anything goes, including trashing it
entirely
—
the branch typically includes the name of the person or team that
so you might see Sandbox-MrMike or Sandbox-NewPhysicsEngine
n
Gold:
The branch submitted for milestone approvals or release
owns it
—
The Sandbox and Gold branches originate from the Trunk branch. Changes in these
branches may or may not be merged with the Trunk branch, depending on what
happens to the code. The Trunk branch supports the main development effort;
almost all of your development effort will happen in the Trunk branch.
The Sandbox branch supports experimental efforts. It
s a great place to make some
core API changes, swap in new middleware, or make any other crazy change without
damaging the Trunk or slowing development there. The Gold branch is the stable
branch that has your last, or next, milestone submission. Programmers can code
fast and furious in the Trunk, while minor tweaks and bug fixes needed for milestone
approval are tucked into the Gold branch.
Perhaps the best evidence for branching code can be found in how a team works
under research and release scenarios. Consider a programming team about to reach
a major milestone. The milestone is attached to a big chunk of cash, which is only
paid out if the milestone is approved. Say this team is old-fashioned and doesn
'
'
t
know anything about branching.
Just before the build, the lead programmer runs around and makes everyone on the
team promise not to check on any code while the build is compiling. Everyone pro-
mises to keep their work to themselves, and everyone continues to work on their own
machines.
Most likely the build doesn
t even compile the first time. One of the programmers
might have forgotten to check in some new files or simply gotten sloppy and checked
in work that didn
'
t compile. By the time the lead programmer figures out who can fix
the build, the programmer at fault may have already started work on other things,
'
