The Joy of Tagging
Tagging is the process of associating a semantic name with a revision number, or changeset. For example, revision 67354 to the repository could be tagged as "stable" or some other name depicting a known state at this revision. The most common tagging example is the "tag for build" or "tag for release" model. In "tag for build", a tag is
created for each build produced. This ensures that an SCM user can find the contents of the repository at the time of a build. Under "tag for release" a separate tag is created for a software release, ensuring years and staff turnover later, we always know what was in "Release 1.0".
But perhaps the biggest byproduct of tagging is the ability to remove dead code. Many software developers are afraid of removing code from a revision control system,
believing that a deletion is a permanent action. Tags ensure that changes between builds, years, releases, or any desired moniker can be easily found. This in turn, enables
code cleanup, refactoring, and deleting. This brings us to the second point: timelines
are not linear.
Timelines Are Not Linear
The most difficult concept in revision control system is the fact that time is not linear, at least not when it comes to software development. At any point in time, a specific revision (which depicts a specific point in time) can become a branch. This means that software released from a revision two years ago, can become tomorrow's branch, or working area.
Supporting applications in the enterprise is a matter of creating branches after the fact, based on a known tag, or bill of materials (BOM). A code line that died years ago can be resurrected and made current, with the creation of another branch. Similarly changes committed prior to refactoring can introduce a new timeline or code line, making two different codelines the present. This brings us to the third point: branching must be easy.
Branching Must Be Easy
While the previous two points are features of the revision control system, this is a best practice. It is vital that branching be as easy to do as possible. Build systems, scripts, and processes need to be designed to ensure that branch names are hard-coded in at most one place. I favour having a branchname file checked into the depot, with anything requiring the branch name reading the file. This ensures that branching becomes a matter of merely updating the branchname file in the newly created branch.
While this obviously helps in branch for release development, it works best in tandem with tagging and timeline creation. The easier it is to create a branch, the lower the support costs for software after a release has been made. In turn, this practice can help your organization better serve the enterprise customer.
Wrap Up
Small teams infrequently follow best practices, nor do they use their tools to the full extent. True understand and best practice implementation of revision control systems helps
SCM increase its value to your organization.
