Labels vs Snapshots

From Seapine Labs

Surround SCM supports the use of labels and snapshot branches. Depending on the situation each can be used to achieve successful source code change management.

Since both features can achieve similar results, deciding when to use each can become confusing.

Contents 1 What is a label? 2 What is a snapshot? 3 When should I use a label? 4 When should I use a snapshot?

[edit] What is a label?

The Surround SCM User Guide states that "Labels mark a version of a file or repository". This logical labels allow you to retrieve a past version of a file that was marked for a specific reason. Some of the reasons users have applied labels in the past may include a release, a build, a defect fix among others.

The benefit of using labels is that instead of having to remember which file version was associated with a release, you can use a more logical approach and instead look for "Release XYZ" label. If you get the file based on that label, you will get the revision associated with release XYZ.

It is important to note, however, that labels in Surround SCM only capture file content. If you do a get based on the "Release XYZ" label, you are only guaranteed that the file content will that of when you applied the label.

You are not guaranteed that the file name will be the same (if the file was renamed after the label) or that the file will be placed in the same directory (file moved after the label).

Because of this, labels are not the best approach to have guaranteed repeatable builds or releases. If you have to do an old build or release and your old build scripts expect a file to have a certain name or be in a specific directory, the build may fail if you use labels.

It is also important to note that a label is applied to a file revision in the database and therefore, may be visible in other branches and repositories (if the file is shared).

There may be also unexpected behavior if labels are used in combination with file sharing. There is a knowledge base articlethat can give you more details, if you are interested.

[edit] What is a snapshot?

A snapshot branch is defined in the Surround SCM User Guide as a static branch. Snapshot branches can not be modified in any way.

Snapshot branch history includes the full history of a file in the parent branch. You can view the actions performed on a file before the branch was created and get, view, or diff files from the parent branch.

Like labels, snapshot branches capture file content. The content can be that as of the time of when the branch is created, a specific point in time, content mapped to a label, or even content mapped to the latest version associated with a state in the workflow.

Note that if you create the snapshot branch based on a label or the latest version mapped to a state in the workflow, the branch will only contain those files that meet that criteria.

Unlike labels, snapshot branches do capture the file name and directory structure as well.

Because of this, snapshot branches are the way to go in order to have guaranteed repeatable builds. Your build scripts for those old builds will be able to find all the files regardless of renaming or moving after the fact.

[edit] When should I use a label?

Labels are ideal if you want to mark a version of a file or files for future reference and there isn't a need or requirement to preserve the original file name or location. Since labels may show up on other branches and repositories, labels should not be used to mark files in a way that only makes sense for one repository or branch.

You could use labels on a group of files to indicate a bug fix or a change request.

[edit] When should I use a snapshot?

Use snapshots whenever you arrive at a milestone, especially those that you may need to come back to in the future. If you may have a need to recreate an old build or release, snapshot branches are the way to go.