How I organize my Local TFS Workspaces

It happens several times on most projects. Developer one, let’s call him Andy, adds a third-party library into the source control repository that isn’t referenced anywhere in the Visual Studio solution file that the team uses. Andy also modifies a few files that depend on this new library and checks his changes in. Developer two, let’s call him Eric, gets the latest from source control by right-clicking the top of the Solution in the Solution Explorer and selecting “Get Latest (recursive)” from the context menu. Although Andy’s local workspace and the build server work fine, Eric believes he has the latest but his code won’t compile.

It’s a frustrating problem with an easy fix: just get the latest copy of the source and rebuild the solution. You can get the latest from the Source Control Explorer in Visual Studio, or open a Visual Studio Command-prompt and issue this command at the root of your solution:

tf.exe get /recursive

I’ve worked to remedy this problem with my teams in several ways, including special buttons you can add to your IDE to make getting to the Source Control Explorer window faster. But when pair-programming on someone else’s machine, my buttons aren’t always available so I drop down to command-line as preferred choice. However, this sometimes has mixed results. If the command-line can’t figure out which workspace you’re in, sometimes it will get the latest from all local workspaces.

I don’t have this problem because I structure my workspaces differently than you. Here’s how I do it.

Multiple Workspaces per Client

This step is optional, but I think it’s worth mentioning. Rather than use a single workspace for all clients, I create one or more workspaces that reflect the client that I’m writing code for. To keep this information visible, I name the workspace after the client instead of the computer name.

I separate my TFS-Workspaces by client for a few reasons:

• Some of my clients have their own repository which requires me to create a workspace for their server.
• When I finish work with a client, I can safely delete an entire workspace without concern of breaking server-mappings for other clients.

Having multiple workspaces for the same client allows me to check out the same branch more than once. This allows me to:

• Use an older copy of the source to reproduce a defect, validate unit tests or to run code analysis
• Work on multiple defects in isolation from one another
• Try out a refactoring in isolation from current development
• Code review of a co-worker’s shelve-set

The practice of having multiple workspaces may not be required for all projects, but it’s a good habit to form.

Client Workspaces separated using Folders

As stated above, I create multiple workspaces for each client. In order to keep those workspaces organized, I keep them separated in their own folder using a simple naming convention (A,B,C, etc). This makes it simple to remove an entire workspace when no longer needed.

Building upon the folder structure that I outlined in my last post (Using Windows 7 Libraries to Organize your code), my folder structure for a client looks like this:

Client	Workspace Name	Folder Location
Client1	Client1-A	C:\Projects\Infusion\Code\Client1\A
Client1	Client1-B	C:\Projects\Infusion\Code\Client1\B
Client2	Client2-A	C:\Projects\Infusion\Code\Client2\A

A,B,C is a simple naming convention, and it doesn’t need to get too fancy. I’ve worked with some projects with some long folder names, but I haven’t yet exceeded the 260 character limit with MSBuild.

Putting it all together

With the above in place, I can check out separate copies of the same branch into different folders: Client1\A\trunk, Client1\B\trunk, etc. Opening a command-prompt at the root of my solution and executing:

tf.exe get /recursive

…gets me just the updated code for that branch. I especially love this approach because I can get latest before I open the solution file, which is immensely helpful because I don’t have to wait for Visual Studio to reload projects if they’ve changed.

Code happy.

Organize your Code with Libraries (redux)

A while back, I mentioned how I was using the Document Library feature of Windows 7 to organize the different types of content on my machine. This approach has worked very well for me since I started, though I have made one small adjustment from the original post: I was keeping both my project documents and code files in the same folder and I’ve since deviated from that. At the time this made sense to keep the documents and source code as close together as possible, but it wasn’t very practical in terms of navigating the code from Visual Studio or when working with multiple TFS workspaces.

Here’s an updated snippet from the original post. My “Code” library is comprised of the following folders:

• C:\Projects\Infusion\Code (my employer) 3
• C:\Projects\lib (group of common libraries I reference a lot) now using Nuget for this.
• C:\Projects\Experiments (small proof of concept projects)
• C:\Projects\Personal (my pet projects)

The main difference is that I’ve added the “Code” folder as the primary container for all my work-related source. Each client that I work with gets their own folder below this root, which provides a convenient way to navigate all of my work projects.

I also now use a “Projects” library that contains an entry for each client. I like this approach because I can set a particular library entry as the default save location, so any time I create a document and click “Save” it will get dumped into a folder for my current client. Here’s a quick peek at my sanitized Project Library.

My next post will show how I organize my Visual Studio workspaces within this structure.