Small teams and small organizations tend to think of SCM as
revision control, and software construction.SCM tools are reduced to the ability to check in and check out
code. Teams rarely use the extended
features and best practices of revision control systems, so let's review how
more efficient revision control can help small teams.
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.
Chayim Kirshen is the Build Manager at Toronto based PlateSpin Ltd., a datacentre automation company.
Trackback(0)
Comments 
Write comment
 |
Articles 
TrackBack URI for this entry
Subscribe to this comment's feed