TFS Workspaces: 2005 and Orcas
Martin Woodward has done a great job explaining workspaces and working folder mappings in a pair of recent posts. For those who are new to TFS or haven’t taken the time to think about the concepts and uses, it’s a good idea to read them.
While his posts apply to both Team Foundation Server 2005 and Orcas, version control adds two new advanced capabilities to working folder mappings in Orcas. I call them advanced because many users won’t have any need for them, as with Martin’s comment about not having a need for cloaks at TeamPrise. However, if you need these features, they are really great.
The first new feature is the one-level mapping. In 2005 and by default in Orcas, mapping a server path to your local disk maps the entire tree under that folder to your local disk. In other words, a working folder mapping is recursive.
If you work on a large code base, you may want to map a top-level directory’s immediate children and then selectively map subdirectories under it. In 2005, the only choice was to map the top-level directory and cloak whatever you didn’t want to get. If you have a large number of directories or the new directories appear rather frequently, it’s a painful solution.
To specify a one-level working folder mapping, you simply add an asterisk to the end of it. For example, the code that the TFS group works on lives in $/orcas/pu/tsadt in our own server (it hosts lots of projects for the Developer Division). There are a lot of directories under $/orcas/pu/tsadt that most TFS developers don’t need in order to work. However, we all need the files in $/orcas/pu/tsadt itself (not recursively) in order to build.
So, with Orcas TFS, we can specify the mappings as follows.
As you can see, the first two mappings are one-level mappings, meaning that only the files directly contained by specified directory are downloaded. Then, I map the directories that I care about. Note that order is not important here: I didn’t have to specify the one-level mappings first. It just turned out that way when I sorted them.
Unless I’m forgetting something (I’m writing this on an airplane), that should pretty much set up a standard TFS developer’s workspace. I’ll spare you the mappings we had to use with 2005, but it’s a lot shorter list.
Mappings under cloaks
The second new capability is active mappings under cloaked mappings. In TFS 2005 we checked for and declared an error for this. There actually wasn’t a good reason to allow it. We had put that rule back in place back in 2003 when the design was different, and we just never removed the check. Funny how that happens.
In TFS 2005 the following would be illegal. However, in Orcas it is supported.
Here I’ve chosen to map all of tsadt, cloak the framework subdirectory, and then map framework\win\core. Now, you have to be careful when you do this sort of thing, because you can quickly create a hairball set of mappings. When you need it, though, it can be really useful.
Why use these features?
So why would anyone need to use either of these two features? One reason is disk space. We work in feature crews when developing new feature crews, so you end up with multiple branches (copies, effectively) of $/orcas/pu/tsadt on your disk. Disk drives are big these days, but you can run out of space with these multi-gigabyte trees mapped to your disk plus the gigabytes of binaries and installation files that hey produce when you build them.
Another reason is bandwidth. We work in North Carolina, and our entire office shares a 10 Mbps line. Even with the version control proxy, it’s worth the time and effort to make sure that you don’t bring down that extra gigabyte if you don’t need it.
Unless you work with really large branches, you won’t care about these features. But if you need them, you’ll love them (and you can try them out with the March Orcas CTP)!
tags: tfs, team foundation, version control, workspaces, working folders, orcas