Source Control
There are many things I like about TFS (including the main one "It's not the abomination known as Visual SourceSafe"). Unfortunately the merge support in TFS 2005 is...well...lacking. Not being able to merge to branches other than a direct parent or child is highly restrictive. Additionally the merge dialogues are frankly confusing. Take the following (preferably far away from me). "Merge changes for me" is relatively straight forward. But what do the other options mean? You could try trial and error, but that's annoying. Fortunately someone at Microsoft noticed this, if not in time to fix in in...
My previous post discussed the general reasons for branching and illustrated structures that support it. In this post I plan to expand on the reasons to use for branching and strategies teams may adopt to make effective use of branching throughout the development lifecycle.There are a number of reasons why you may wish to use branching in your system. Some of the major ones are:To allow the development team to be more effectively utilised. You will not necessarily want or need the entire team to be working on stabilising a version rather than working on new features. Additionally where breaking...
Consider a simple solution structure in source control such as that shown below. It is based at the root of the source control structure, and the projects of the solution are at the first level of the source control structure.This is a typical naive usage of source control. It works in that it allows developers to share their changes and provides history for all changes over time. Unfortunately, this structure is not without drawbacks. I'll start with some of the issues with the structure of the project itself and work up to larger issues with the overall organisation.One of the...
The structure contained within a source control repository looks very much like a file system. It contains what is (at least conceptually) a structure of directories and files. Where the repository extends this view is in its inclusion of history information. Items in the repository are given a version number on creation. On every modification a new version of the item is recorded. This is done in an additive fashion such that existing versions are immutable (barring special purpose administrative tools). In addition to the item itself a version will contain metadata such as a timestamp and the user who...
Although source control systems can detect and assist in the resolution of conflicting edits this is not sufficient to prevent developers from checking in incompatible changes. If the behaviour or interface of a type or collection of types is modified by a developer it is reasonable to assume that they will make appropriate modifications elsewhere in the system to account for these changes. However other developers working concurrently will not have these changes and will produce code that uses the old behaviour.As an example, take the TestItem class from my previous post. Developer A modifies the signature of the CalculateResult...
My previous post discussed the basic get and checkin operations that are key to the operation of source control. It also indicated that these operations are not in practice sufficient to build a usable change control system. This post will discuss why and go through the mechanisms source control systems use to address these problems.Take an example system which contains the class TestItem.cs, defined as:public class TestItem{ public int FirstValue { get; set; } public int SecondValue { get; set; } public int CalculateResult() ...
The fundamentals of source control essentially boil down to two elements: Repositories and Working Copies. All activities perfomed using source control involve interaction with one or both of these elements.The repository is the ultimate source of truth in the system. It contains the latest version of every item under source control. Additionally it contains a history of all the revisions of each item. This allows the state of the repository at any point in time to be recreated. By querying the repository you can determine such things as what changes were made in particular time periods, what changes a specific...
This is the first in what may (or may not) be a series of posts on source control written to prepare for a presentation I'm doing on this topic.Source control is one of the fundamental elements of any professional software development effort. Desirable in single person development, it is mandatory in a team environment.The naive view of source control is that it is a backup mechanism to guard against the loss of work due to factors such as failure of a development system. This is an important function but represents only a small fraction of the worth of a source...