Udostępnij za pośrednictwem

Rounding the Baselines

  • Artykuł

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.

Comments

  • Anonymous
    April 19, 2005
    I just finished readding "Software Configuration Management Patterns" by Berczuk and Appleton. ISBN:0-201-74117-2.

    It would be a great place to get a handle on terminology.
  • Anonymous
    April 19, 2005
    So Label and Branch may be two alternatives to baseline. The good thing is I found in Team Foundation Version Control it is possible to apply a label to a version chosen by a changeset, date, workspace or even label.
  • Anonymous
    April 25, 2005
    Visual Studio Team System
    Beta 2 is out and thousands of you have downloaded and installed it with varying...
  • Anonymous
    June 18, 2005
    If you use labels as baselines to tag all the elements in the repository at different points in time, can you later compare those labels to obtain the files that where changed?
  • Anonymous
    August 05, 2005
    Pablo-

    Yup! Labels are a valid version specification. To compare a file between labels 'label1' and 'label2', run "h diff file.txt;Llabel1~Llabel2" (soon to be "tf diff...").

    Hope this helps!
  • Anonymous
    March 08, 2006
    Very good information in label and branching since we are planning to migrate VSTS to replace VSS.