Share via

Grab your map and cloak, we're looking at the workfold command

  • Article

One of the first features of Team Foundation Version Control (man, do I miss calling it "Hatteras") was the "workfold" command.

This is the command line client command to manage which files and folders from the version control repository appear on your hard drive and how they're arranged. Let's start with a simple example:

   h workfold /map $/ c:\sources

This command maps the root of the repository to the local folder c:\sources. If you then did a recursive "get", you'd end up with a full copy of all files in the repository on your machine arranged in the same folder structure as they appear on the server.

A more likely mapping would be the root of a team project folder mapped to a folder on your drive:

   h workfold /map $/HelloWorld c:\MyProjects\HelloWorld

Now, say there's a sub-tree under the HelloWorld folder of files you never intend to touch... a folder called "UnitTests", for example. If you wanted to get all the files except the files under $/HelloWorld/UnitTests, you could use the cloak command:

   h workfold /cloak $/HelloWorld/UnitTests

You can view your current working folder mappings and cloakings by using the workfold command without any parameters:

   c:\MyProjects>h workfold

   ===============================================================================
Workspace : JASONBA1 (jasonba)
Repository: teamserver1
$/HelloWorld: C:\MyProjects\HelloWorld
(cloaked) $/HelloWorld/UnitTests

At this point, we've only scratched the surface of what you can do with mappings and cloakings. Let's move on to a more advanced example.

You can map a file or folder on the server to any name in your local workspace. For example, say your team has checked in a stable version of a class file at $/HelloWorld/Classes/helpers.cs. Now, maybe you're working on a re-write of the helper class. You could just check out the file and edit it on your local machine, but you probably want to check it in from time to time to back it up. So let's say you check it into $/HelloWorld/Classes/NewHelper.cs. 

If you wanted to see how the team project would build using your new class instead of the stable version, you could cloak the stable version of the file and map in your version. Here's how:

   h workfold /cloak $/HelloWorld/Classes/helpers.cs

   h workfold /map $/HelloWorld/Classes/NewHelper.cs c:\MyProjects\HelloWorld\Classes\helpers.cs

Now, when you build your local copy of the project, your new helper class will be used instead of the original one. But anyone else who syncs the project from the repository would still get the stable version (unless they copied your wacky mappings/cloakings).

Comments

  • Anonymous
    January 23, 2005
    Very COOL,
    Keep them coming. Great post
  • Anonymous
    January 24, 2005
    Keep in mind that the mappings are not versioned, so they should not be used to replace a build script, which is versioned.
    In other words, if your build system depends on having the mappings create the directories in particular locations on your disk, you will likely have trouble building older versions of your software if the required locations change over time (unless you carefully record what the necessary mappings are for each of the versions, but it's easy to forget).
  • Anonymous
    May 05, 2005
    We've been getting some feedback that the "workspace" concept isn't entirely clear. In my post on baselines,...