Friday, July 29, 2005
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 following article gives an overview of the prevailing branching models in Software Configuration Management.
Please click below to download a copy of this white paper.
SCM Best Practices - Uttam Narsu
Wednesday, July 27, 2005
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.
Friday, July 22, 2005
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:
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.
Thursday, July 21, 2005
The following article is a great introduction to SCM.
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.
Monday, July 18, 2005
- 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 126.96.36.199, 188.8.131.52, 184.108.40.206, 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.