Check In Early and Check In Often

Developers often put off checking in. They put it off because they don't want to affect other people too early and they don't want to get blamed for breaking the build. But this leads to other problems such as losing work or not being able to go back to previous versions.

My rule of thumb is "check-in early and often", but with the caveat that you have access to private versioning. If a check-in is immediately visible to other users, then you run the risk of introducing immature changes and/or breaking the build.

The nice thing about private versioning is that in most cases the versions checked in are stored on the server and available to other users if they need them, but don't cause problems the way that making them public can.

I find that when developers have access to private versioning, they tend to start relying on it and it requires no effort on the part of the cm admin to "enforce."

The Importance of Branching Models in SCM

Complex code bases, massive parallel development and other problems often plague a project and can bring it to its knees. A number of Configuration Management and Source Control products and processes exist to help try to tackle these growing problems. But which one is best suited for a particular release structure and build environment? A number of branching models exist that each have their particular strengths and weaknesses.

The following article gives an overview of the prevailing branching models in Software Configuration Management.

Software Configuration Management (SCM) Best Practices

Uttam Narsu is an industry expert on software configuration management best practices. While an analyst at Giga and Forrester Research, Mr. Narsu worked with hundreds of differing software development environments and has put together these SCM best practices in this compelling white paper (January 2005).

Please click below to download a copy of this white paper.

SCM Best Practices - Uttam Narsu

Source Control Using CVS, Subversion, and AccuRev

A couple of weeks back, Robert Warner, of Availity gave a presentation to The Jacksonville Developers User Group titled "Source Control Using CVS, Subversion and AccuRev."

The link to his presentation can be found here.

He also, in one of his subsequent blog entries, addressed the audience's question of the criteria against which he and his company had evaluated the tools. The blog entry is simply titled "Source Control."

His is a great overview of the major features and functionallity of some of the SCM product solutions out there.

Enjoy.

Timesafe - Immutability in Software Configuration Management

The link below points to a paper that I wrote a few years ago regarding Immutability in Software Configuration Management.

Abstract. A basic function of Configuration Management (CM) is to accurately reproduce past and present information. Many other aspects of CM depend on this function. Flaws in this function affect and are magnified by other aspects of the system. Ideally, a CM system should perform this basic function automatically and flawlessly without any special knowledge or effort on the part of the users. This paper introduces the Timesafe ® property to describe CM models that possess the capability of accurately and automatically preserving and reproducing past and present information. As a first step towards enabling the proof or disproof that a CM model is Timesafe, this paper provides a formal description of the Timesafe property and the currently known list of counter-examples.

The paper can be found here:

http://www.accurev.com/blog/Timesafe%20-%20Immutability%20in%20CM.pdf

This is one of the core competencies that I believe to be integral in Software Configuration Management products, especially in the dynamic, distributed and parallel development environments that we as CM professionals must try to manage.

What is Software Configuration Management?

The following article is a great introduction to SCM.

http://www.informit.com/articles/article.asp?p=390813&rl=1

Article Brief

Software is easy to change—too easy. And not only is it easy to change, but it is unconstrained by the physical laws that serve as the guardrails of what is possible with hardware systems. Software is bounded only by the limits of the human imagination. Uncontrolled and undirected, imagination can quickly give rise to nightmare. Software configuration management helps to limit this.

A Vocabulary for Software Configuration Management

The beginning of any good conversation requires that a lingua franca be created so that the participants have a common vocabulary and thus assurance that they are comparing apples to apples. SCM is certainly no different. Therefore, in the interest of laying a foundation for further postings, below is an abreviated list of concepts and terms that will help us understand one another:

• Attribute - An attribute is similar to a label. An attribute is a named value that is associated with a version. One use for attributes is to tag a version with a change request number to identify which change it is a part of. Some systems allow attributes to be applied to other objects, such as branches, as well.
• Branch - A branch is a point of divergence. It starts a new, uniquely named series of versions from an existing version. Different systems use different naming schemes. In RCS [Tich85], a new numbering sequence is added. Creating a branch off of 1.1 in RCS might create a new sequence such as 1.1.5.1, 1.1.5.2, 1.1.5.3, etc. In ClearCase [Rati96], there is an initial branch, /main, which begins a sequence that looks like this: /main/1, /main/2, etc. Creating a branch off of /main/2 in ClearCase would record internally that the branch was rooted at /main/2 and the new sequence would look like this: /main/gizmo/1, /main/gizmo/2, etc.
• Change-set - A change-set represents a logical change. It is the set of all changes that must be applied to a previous configuration to derive a new configuration.
• Configuration - CM is typically applied to logical groupings of objects. For instance, you might want to use CM to manage all of the files that are used to build a product or all of the files contained in a web site. A configuration is one instantiation of whatever it is you are managing. You might have a configuration that represents version 1.0 of a product, or a configuration that represents new product development.
• Configuration Definition - A configuration definition is a recipe that is used to specify the exact contents of a configuration. The definition is constructed from the names, versions, timestamps, labels, branches, attributes, and/or change-sets from one or more repositories.
• Configuration Name - A configuration name is a reference that is directly understood by the CM system and can be used to specify the configuration definition. The system uses its configuration name dictionary to automatically translate configuration names into configuration definitions. Object - Typically files and directories.
• Label - A mnemonic name (alias) used to refer to a particular version.
• Object Mastership - When using replication, each object that has a copy at multiple sites is mastered at one and only one site. That is, that site owns the object and updates to that object may only be made at that site.
• Object Name - Typically file and directory names, but can be anything used to uniquely identify objects in a repository.
• Repository - A repository provides storage of all names, versions, labels, branches, attributes, change-sets, and configuration definitions.
• Replication - For efficiency, it is often desirable to make a copy of all of or part of a repository at one or more geographically separated sites.
• Synchronization - Periodically, it is necessary to update replicated repositories with new information. This process is called synchronization.
• Timestamp - The time at which an action was performed. Usually, each version is timestamped in addition to being numbered. Timestamps are often the time at which a transaction was performed.
• Version - Usually a monotonically increasing positive integer starting with 1 used to designate the different contents of an object over time. Any designation which uniquely identifies a version will suffice.

This is a good start... next onto what these terms mean in the context of SCM.