Private Branches

A private branch is a code line in your VersionControl system that is not the public, main line. It's not necessarily unreadable to other developers -- it's just not the public line, the one that everyone releases to.

In the context of XP, why would you use PrivateBranches?

RobertWatkins offers these reasons:

Private branches offer the following benefits:

You can commit changes to a task prior to delivery, allowing you to rollback subsequent changes that didn't work. Visual Age users would be familiar with this sort of work. It's also possible to do this in Eclipse, with their Local Workspace History tool. Think of it as an extended undo.
With this sort of support, you can follow Kent Beck's advice: whenever you get an unexpected test failure, simply rollback to your last committed version (which should be all of five minutes old).
If you use an integration machine, private branches offer a convenient way of moving the code over; simply check into your private branch, merge it into the integration box, test, then commit to the main branch.
Implement a version controlled SpikeSolution using the main code base without disrupting others. Branches are more commonly seen in the distributed OpenSource arena, where non mainline experiments are long lasting in order to have time to percolate out to a wide variety of test platforms.

Other people offer reasons not to use PrivateBranches in XP, including:

They encourage developers to delay integrating (i.e. interfere with ContinuousIntegration).
They require some extra effort to use, which they may not make up for in benefits.
Some VersionControl systems implement them in clumsy or slow ways (see previous).
They lead to the psychological sense of being separated (great way to build a team, allow everyone to work on their own bits) [this is far from trivial, it may be the most important aspect].

Robert really likes the private history aspect of private branches:

Talk to Kent. He's been quoted lots of times as saying that he prefers to be able to rollback his changes every time he breaks a test unexpectedly. He loses a few minutes work at best. Of course, Kent probably spends a lot of time working in VisualAge Smalltalk, which gives every developer a "private branch" to work in. Ditto VisualAge Java, an IDE regularly quoted as being "the best XP IDE around".

Eclipse, the VAJ replacement, goes one step further. Rather than relying on you committing into the repository, it does versioning for you in your "local history". Every body gets their own branch, and it's on their own machine!

So the rollback benefit is there even if you don't use the VersionControl system to implement it. Couldn't I get the same rollback benefit by just tarring my local copy of the project frequently? Maybe the command could be run every time I run the tests. --GeorgePaci

An alternative would be to use a DistributedVersionControl system such as Darcs: in a distributed SCM environment, every working copy is at the same time a repository, and a branch from the "main" trunk (which may in fact be branched from another repository). Plus the merging and changeset-handling abilities of distributed SCMs are leaps and bounds beyond those of centralized SCMs, because they need to be.

Robert also provided a handy-dandy guide to using private branches in CVS:

(Caveat: command switches may not be exactly right... I'm working in ClearCase these days).

When you start your work, execute the following:

# gets a clean copy of the trunk.

  cvs update -R -A -C

# Tags the trunk, and sets up the branch.

cvs tag -R -f -b -F MY_TAG_NAME

When you are ready to integrate, on your box you simply do a commit. Then, on the integration box:

# merge in any changes from the MY_TAG_NAME branch.

  cvs update -R -j MY_TAG_NAME
  <run integration tests>

# commit the changes to the trunk.

  cvs commit -R

# Optional: remove the tag name from CVS; any branches will still exist.

cvs tag -d MY_TAG_NAME

[Anyone want to follow this recipe, to verify the commands and switches?]

Of course, when using PrivateBranches in XP, you should still do XP:

Start a task by updating your private branch to be whatever's in the main line.

End a task by merging your private branch into the main line. (This should happen at least once a day.)

JohnMitchell?: A team member creating a branch so as to avoid being part of the team is almost always A Very Bad Thing(tm).