Adam Singer

Veni, vidi, expertus sum- I came, I saw, I tested

Rounding the Baselines

Bruce from GrapeCity Inc. asks:

When reading something about version control I learn a term “baseline”. But in TF version control, I did not find it but a new term “workspace”. I feel the two terms have similar meanings. Is my understanding right or not?

PS: The TF version control is much much better than the old VSS. 🙂

Good question, Bruce. Chris, Sam, and I joined forces to help come up with an answer for you.

What we think this question really drives at is the versioning scheme and branching functionality of Team Foundation Version Control. With a combination of the two, we provide several alternatives to baselines depending on your particular goal.

A quick aside for any of those joining us who haven’t heard the term “baseline”. According to this guide, baselines are collections of particular revisions of items in version control. This baseline is then generally defined as a stable state. See also this email for more on the subject.

Before we get to version specifications and branching, though, I’d like to explain the concept of “workspace” to better compare it with that of a baseline. Workspaces represent client state and mappings of where to download items from the server. An individual workspace is owned by one user on a particular machine. When the user gets items from the server, their workspace is updated to store what versions of the server items the client has. Maps and cloaks help define what parts of the repository the workspace should retrieve. See Jason’s post on the topic here for more on the subject.

One major difference between the two is that workspaces are intended to belong just to one person while baselines are shared. Baselines generally change somewhat infrequently, whereas a workspace is expected to be updated on frequent basis as development progresses. This is where the other version specifications come into play in Team Foundation.

There are multiple different types of version specifications. The first, which I’ve recently discussed, is changesets. These represent a snapshot of the entire repository state after a checkin occurred. Date version is similar to changeset since at any given time there is one set server state. There’s also the “tip” version which is the latest version of all items in the repository. Workspace version represents the latest version retrieved by the specified workspace (or current workspace if no workspace name is provided). The most complex is the label version spec.

A label is an arbitrary collection of particular versions of items in the repository. Once a label has been created at a given scope (i.e. directory), it can be applied to any version of items in the repository under that tree. Each item may have only one version in a particular label but each version may be in any number of labels.

This leads us to one potential equivalent of baselines. If you use a baseline as a version snapshot, labels are the way to go. Items can be added and removed from the label as well as updated, like baselines. If however, you want to split version 1.0 and 1.1, we have the concept of branch.

The branch command creates a new copy of the specified items and stores information about common ancestors for use in future merges between the branches. More on branches can be found in Buck’s post here. So, if we wanted to call the new branch v1.1, the changeset in which we check it in would be the baseline. We could also create a label at this changeset for easy reference later on. Note that a user could have both branches of the source code mapped in their workspace simultaneously if they happen to be working on both hotfixes and new features.

In short, the particular equivalent of baselines depends on the intent and expected use. However, I believe we offer the right tools to get the job done.