Sometimes you want to rapidly evaluate a complex change that may break the sys-tem while maintaining an ACTIVE DEVELOPMENT LINE (5). This pattern describes how to maintain local traceability without affecting global history unintentionally.
How can you experiment with a complex change and benefit from the version con-trol system without making the change public?
Some programming tasks are best done in small, retractable, steps. If you are making a complex change, you may want to checkpoint an intermediate step so that you can back out of a change easily. For example, if at there are a number of design choice
points, you may want to explore one path, and be able to back out to an earlier deci-sion point when you see a problem with the implementation, as in Figure 16-1
Your version control system provides a way of checkpointing your work, and revert-ing to earlier states of the system. When you check somethrevert-ing in to the active code-line, you subject every other member of your team to the changes. When you are exploring implementations, you may not want to share your choices until you have fully evaluated them. You may even decide that the change was a dead end.
If you don’t want to use the version control system to track your changes, and not cause other developers delay, you will have to test your changes in accordance with your codeline policy. You may also need to integrate changes so that other code works with any API changes that you made. This can take an unjustifiably long time if you are just experimenting with options. If you decide to skip the tests, you will cause problems for other developers if you break the build, or the built system. If you skip integrating your changes with the rest of the system, you will break the code-line.This is too much work for a change that you may throw away in an hour, or a day. Figure 16-2 shows still another option; you can check in changes at and revert at Figure 16-1 .Each decision leads to more choices, until you pick the solution.
each step. This generates many superfluous change events for the rest of the team, and only gives you one the ability to retrace your changes one step at a time.
Even if you did put the effort into validating changes before checking them in, you will be cluttering the version history with changes that are not salient to the main change path. Since the version history for a component is important, it may be impor-tant to keep the version history uncluttered with insignificant changes.
You might consider just doing all of the changes in your workspace and not checking in any intermediate work. If you don’t check in any changes, you can’t back off changes.You can take an ad-hoc approach to saving the state of your work at various points in time by copying files or using some other mechanism, but then what you are really doing is creating a minimalist version control system. It’s optimistic to expect to develop a mechanism that gives you the features that you want reliably without investing more work than is appropriate is optimistic.
You can also use private versions to test how integrating with the current state of the codeline will work with your software. You can check your changes into your private version, then catch up with the codeline, and then easily roll back if there is a prob-lem.
The dilemma is that you want to use the tools of your trade, including version con-trol, to create a stable, useful, codeline, but you want to do this privately.
Figure 16-2 .Using the Code Line for staging generates a lot of noise.
check in
Revert
check in
Use Caution
Being able to version control without publishing changes is one of the things that you only miss when you don’t have it. When the practice isn’t established, people often avoid the issue entirely. The times that I’ve seen this used in practice are situations involving major refactorings, or developing proof of con-cepts.
Being able to rollback bad ideas before everyone sees them is very helpful.
A Private History
Provide developers with a mechanism for check pointing changes at a granularity that they are comfortable with. This can be provided for by a local revision control area, Only stable code sets are checked into the project repository
Set up a developers workspace so that they can check in changes to a non-public area when they are making an appropriate change. The mechanism should allow them to also integrate their working code base with the current state of the active develop-ment line. This private repository should use the same mechanisms as the usual ver-sion control system so that the developers do not need to learn a new
meachanism.This allows developers to experiment with complex changes to the code base in small steps, without breaking the codeline if an experiment goes awry. This allow developers to make small steps in confidence, knowing that they can abandon part of a change if it takes longer than they expect.
There are many ways to implement this. One way is to have an entire PRIVATE WORK
-SPACE (6) dedicated to a task. This is appropriate when we want to experiment with a global change (for example, to an interface) and wants to evaluate the consequences of the change to see if they are manageable in the time that they have. If your change involves only a small portion of the source tree (one java package, or one directory) you can map that part of the workspace to a ‘private’ repository, for example, a local CVS repository, or a developer specific branch of the main repository that is not inte-grated with the active line. You then redirect certain check ins to the private reposi-tory. When you are done with your work, check the files into the main repository, either by specifying the repository, or copying files from the test workspace to your
real one. Be sure to follow all of the procedures in your standard codeline policy before checking the code into the active codeline.
Some tools provide for promotion levels or stages. You can create private stages to use version control and not publish changes to the rest of the team.
It is important to make sure that developers using Private Versioning remember to migrate changes to the shared version control system at reasonable intervals. While one way to implement this is to provide a separate source control repository for each developer, in addition to the shared repository, this can also be implemented within the framework of the existing revision control system. If the revision control mecha-nism provides a means for restricting access to checked-in versions that are not yet ready for use by others, we can use the common version control system as a virtual Private Repository.
The important principle is to allow the developer to be allowed to use the version control system to checkpoint changes in an granularity which meet their needs, with-out any risk of the changes (which may be inconsistent) being available to anyone else.
Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Steve Berczuk with Brad Appleton. Copyright 2002 Addison-Wesley, Boston, MA. All rights reserved