Part I: Why Branching Doesn’t Work
Part II: Labelling, Branching’s Poor Cousin
Part III: Apps Without Source Integration
In the first part of this series I explained why branching might not be the best strategy for versioning “configuration” files. These are items that control or influence an application but aren’t an integral (compiled) part of it, and often have a different development and release cycle. In this part I offer a solution and then, ahem, gripe about the tooling for it.
The solution is labelling – a completely flexible way of identifying specific versions of specific files. The concept is very similar to tagging photos on a photo-sharing site or posts on a blog. The label itself is a simple text string and can be anything you like. You can apply one or more label to any version of any files. Unlike changesets, which cannot be modified after creation, labels can always be updated. Unlike branches, which are driven by changesets, labels don’t push you into a rigid work flow or strategy. About the only thing you can’t do is apply the same label to more than one version of the same file, but I can’t imagine a realistic scenario where you would want to do that.
So that’s sounding nice and simple, right? Just label up the config files you want to release together, modify the labelled files if something changes or needs fixing, and when it’s all ready get the labelled files out of source control and deploy. Easy. Well, it would be if the Visual Studio support for labelling wasn’t so cursory. It seems like all the effort went into branching, and labelling was dismissed as the poor man’s configuration management – a clumsy oaf stamping random files with ill-named tags, compared to the sophisticated beard-stroking intellectual that is branching. Don’t get me wrong, branching is great, but not everybody is versioning branch-friendly application source code (and dependant artifacts) alone.
Here’s what’s not up to scratch in the Visual Studio 2010 support for labels:
- The Source Control Explore context menu option Apply Label doesn’t apply an existing label, it creates a new one. The dialog that pops up is called New Label with a button named Create so it knows its own purpose, even though the menu item doesn’t. Understandably, people try to use this to apply an existing label to additional files. When they do (and don’t read the next dialog carefully) they wipe out the existing label completely and start from scratch with a new label. One mistake like that is enough to convince people labels are too risky to depend upon.
- Apply Label only allows one file or folder to be selected. As Apply Label can only be used once per label (see above) why not let users label multiple files at the same time?
- You can’t select files in source control and apply an existing label.
- You can’t select a version of a file from the history and create a label or apply an existing label.
- You can’t easily apply a label to every file in a changeset.
- The label editor (the only way to modify a label) is hidden all the way under File –> Source Control –> Label –> Find Label. Yes, it’s also accessible from the label tab of a file’s history, but to get to a specific label that way you need to know a file that has it applied and navigate to it.
- The label editor has a Change Labelled Version button but a more direct Update to Latest feature would be nice – much of the time when you change the labelled version that’s what you want to do.
There’s a lot that could be better, but despite it all the TFS labelling implementation is sound at it’s core, and despite its awkwardness the tooling is usable. If someone could crank out a VS extension that fills the GUI gaps it would be perfect. Watch this space…
Once you have your label correctly applied you will want to get the right versions of the right files so they can be deployed. You can simply Get the label from the root of a workspace to clear out other files and get the labelled files alone. You probably won’t want to use your normal workspace for that, as the operation may well interfere with normal work (and vice versa). You could manually create a second workspace for getting labels, but I find a batch script is cleaner:
@ECHO OFF SET ProjectCollection=http://MyServer:8080/tfs/MyProjectCollection SET TeamProject=MyTeamProject REM Prompt for label name SET Label= SET /P Label=Enter a label to get from TFS: IF "%Label%"=="" GOTO Exit REM Setup workspace (fails non-destructively if it already exists) C: CD \ MD TFS CD TFS MD DeploymentWorkspace CD DeploymentWorkspace "%VS100COMNTOOLS%..\IDE\tf" workspace /new /collection:%ProjectCollection% DeploymentWorkspace /noprompt CLS ECHO Getting labelled files to C:\TFS\DeploymentWorkspace... ECHO. "%VS100COMNTOOLS%..\IDE\tf" get . /version:L"%Label%"@$/%TeamProject% /force /recursive REM Check if label exists (error TF14064) "%VS100COMNTOOLS%..\IDE\tf" dir . /version:L"%Label%"@$/%TeamProject% /recursive >LabelContents.txt 2>&1 SET /p LabelContents=<LabelContents.txt DEL LabelContents.txt SET LabelContents=%LabelContents:~0,7% IF [%LabelContents%]==[TF14064] GOTO Exit ECHO. ECHO Copying to Desktop folder %Label%... CD "%USERPROFILE%\Desktop" MD "%Label%" CD \TFS\DeploymentWorkspace xcopy %TeamProject%\* "%USERPROFILE%\Desktop\%Label%\" /s ECHO. :Exit pause
That’s it! The next part looks at the challenges of versioning config files that are not edited within Visual Studio.