Post a Comment On: the urban canuk, eh

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. [Image] 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.