Fortunately, there is a way to test a fix to a running server without updating the files on the server and without impacting anyone else.   The way to do this is through Fiddler’s AutoResponder feature.  Effectively what you are doing is using Fiddler to intercept the request from the browser for a given JavaScript file and telling Fiddler to return a local file instead of making a request to the server.   This can be a huge time saver.

Here are the steps:

Suppose you want make a change to SomeLibrary.js to fix a bug.

1. Clear the browser cache

2. Open Fiddler

3. Navigate to a page the loads SomeLibrary.js

4. Right click on the list item in Fiddler that requests SomeLibrary.js from the server.   Select Save, Response, Response Body… and let’s use c:\temp\SomeLibrary.js as the file name

5. In the AutoResponder tab check “Enable automatic responses” and “Permit passthrough for unmatched requests”

6. Drag the list item from step #5 to the AutoResponder window.  At the bottom type c:\temp\SomeLibrary.js and press Save.  

7. Make change to c:\temp\SomeLibraryjs to fix bug

8. Clear the browser cache

9. Repro steps for bug in browser.  Since Fiddler is a proxy for the browser, Fiddler will respond to a request for SomeLibraryjs by returning your modified file, c:\temp\SomeLibrary.js.

If your fix did not work, simply repeat starting at step 7.

Using the Fiddler Autoresponder feature allows you to safely test a JavaScript change to a production environment without affecting other users and without spending the time reproducing the problem in an separate environment. 

Unfortunately, security measures have a tendency to not only deter the bad guys, they also create some pain for everyone else.  The same is true for MVC’s AntiForgeryToken.  You can add AntiForgeryToken to your ASP.Net MVC web application to perfection and still leave the honest user seeing “HttpAnitforgeryException – A required anti-forgery token was not supplied or was invalid”. 

How can this be?  Well, I ran into this recently in the development of Team Web Access and found two interesting causes.

1. Browser restores last session on browser start up for page that is cached

If you have a page that is cachable that performs a post to your server (i.e. antiforgery will be on) and the user has their browser set to restore last session on start up (e.g. this option exists in the Chrome browser) the page will be rendered from cache. However, the __RequestVerificationToken cookie will not be there because it is a browser session cookie and is discarded when browser is closed. Since the cookie is gone you get the anti-forgery exception.

Solution: Return response headers so that the page is not cached (i.e. Cache-Control:private, no-store).  If your page returns quickly from the server (which ideally it should) the impact of this change will be unnoticeable.  If this page takes a long time to render on the server than this solution will be less than ideal.

2. Race condition if opening more than one tab on start up to your site

Browsers have the option to open a set of tabs at start up.  Moreover, if you apply Windows updates with Internet Explorer open it will restore all of your open tabs.  If more than one tab hits your site that returns a __RequestVerificationToken cookie you can hit a race condition where this cookie is overwritten. This happens because more than one request hits your server from a user that does not have the request verification cookie set. The first request is handled and sets the request verification cookie. Next the second request is handled, but its request also did not have a cookie in the request headers so the server generates a new one. The new cookie overwrites the first one and now the first page will get an antiforgery request exception when it next performs a post.  The MVC framework simply does not handle this scenario at this time, so you need to implement your own solution if your customers are hitting this scenario. This issue has been reported to the MVC team at Microsoft. 

It took quite a bit of logging on the server and questions to Microsoft internal and Team Foundation Service Preview users to track down these two causes.  It was important to us to understand and solve this issue because we were getting regular reports of it from our customers.  We did not want a security measure meant to deter a hacker to cause pain to the honest customer using Team Web Access.

The TFS way to do a given Subversion Task

Importing Code

Subversion has an import command to add files and folders to an SVN repository.  Once a folder structure is created, files and folders can be added using svn add.  TFS does not have a separate import and add operation – instead it is all done with the tf add command.  TFS does require a workspace (think working copy directory mapping) to be defined to map local folders to server folders.  In Visual Studio the workspace is created automatically for you if you drag and drop files onto Source Control Explorer or if you add an existing solution to Source Control.  To do this from the command line in TFS you do the following:

1. cd into the top level folder you want to add
2. Create a workspace - tf workspace /new
3. Select the server path you want to add the folder to in the dialog
4. Press OK
5. Pend the add of the folder and it’s contents recursively by performing the following command.  tf add .\ /r
6. tf checkin

SVN Checkout and TFS Checkout are NOT the Same

One area of confusion for users moving from SVN is the term checkout.  SVN checkout is the way to pull files and folders from the SVN repository to create a working copy locally.  You typically only do this once and when you want later revisions you run svn update.   The TFS equivalent of SVN checkout is creating a workspace mapping and performing a tf get which will copy the files from the server into the local files you defined in the workspace.

A TFS checkout is completely different than the SVN checkout command.  TFS checkout is the way the user tells TFS they plan to make a change to a file.   TFS checkout changes the file’s attributes from read-only to writable. 

SVN Update

The update command is used to get the latest or a specific revision from the SVN repository to the working copy.  The TFS get command accomplishes the same thing.   However, there are a few key differences on behavior. 

1. SVN will look for missing files and place them in the working copy.  TFS does not do this.
2. SVN pulls down an extra copy of the file and places it in the .svn directory.  TFS does not pull down an extra copy which means the space on disk that a TFS workspace takes is at least 1/2 the space that SVN uses.
3. SVN pulls down files as writable while TFS pulls down files that are not checked out as read-only

SVN Commit

SVN commit (aka ci) is the equivalent of tfs checkin.  Where they differ is

• tfs checkin has many additional features (see New Things you can do in TFS section below) 
• After the checkin tfs makes the file read only while svn leaves the file writable

SVN Snapshots

SVN users create snapshots of changes using the copy command and tags (see here).   TFS has a single command called shelve that copies changes to the server with a specified name.  Shelved changes are a called shelveset.  Shelvesets are a bit cleaner than SVN snapshots in that they do not pollute  the folder structure of the repository. 

Mapping SVN Commands to TFS Commands

New Things You Can Do in TFS

There are many new things you can do in TFS (and we keep adding more :-) that you cannot do in SVN.  A few of these are highlighted below.

Advanced Check-in Features

TFS checkin has many capabilities not found in svn commit.  For example, you can associate or resolve a TFS Work Item (e.g. bug) with the check-in which creates a link between the changeset and the work item.   You can also enforce rules at check-in time by creating check-in policies that require a comment or require that the developer ran unit tests before checking in.  You can also configure well formed comments with required fields via the TFS check-in note feature. 

Visualizing Changes

Nothing communicates like a picture and TFS communicates where a change is or where it came from visually with Branch Visualization.  The Ed Square blog cover it here.

Destroy

TFS allows users with the proper permission to remove content permanently from the repository.  This is handy to reclaim space when someone accidently adds that 6 GB media file.   It is also essential if you need to remove code for intellectual property reasons.

Enjoy TFS

Although SVN and TFS have many features in common, they differ in places with their respective approach and have their own unique features.  With a little learning and the right map (see above) the move from SVN to TFS can be painless and productive.

The same is true with bugs - you want to fix the highest priority bugs that are the biggest (most time) and fragile (complex) first.  Think of the moving truck as the amount of time and resources you have to fix bugs.   To optimize this space bugs should be fixed in priority order with the most difficult and time consuming ones first.  You can fix the smaller and easier ones late in the game without jeopardizing the schedule.  If you wait too long to fix difficult bugs there is increase risk to the schedule because there is not enough time to test the fix OR the a fix won't be provided at all because of the risk.  In either case, the quality of the product suffers.

Often in practice, the exact opposite behavior happens.  Teams want to show measurable progress so even though they may fix bugs in priority order the easy ones tend to be done first. 

Quick - go look at your bug form.  Go ahead, I'll wait....  Is there a field that quantifies the level of difficulty of the fix?  Most likely the answer is, "no".   Some imply this from the priority or severity of the bug.  However, this is often not the case.  For example, a null ref crash is priority\severity 1, but is often trivial to fix.

Specifying Difficulty

Specifying the difficulty of fixing a bug is like any other software estimation practice - it is not an exact science.   Sometimes you are not really going to know unless you dig into the bug more.  Avoid spending too much time trying to determine a precise level of difficulty, the goal is to get the right order of magnitude. 

Quantifying the difficulty of addressing a bug should factor in 3 elements:

1. Complexity\risk - how many components and moving parts are involved?
2. Duration - gut estimate of how many hours/days it will take to fix and test
3. Expertise - does this bug require rare specialized knowledge?  If so, get this fixed as soon as that expert is available

You can keep it simple and use T-shirt sizes to measure difficulty - small, medium, large or use a numeric value.  Some may find it valuable to place duration is a separate field for scheduling and load balancing purposes.

Regardless of how you specify the level of difficulty, fixing bugs in priority and highest level of difficulty order will decrease risk and improve the quality of your software.  Don't be left with the refrigerator not fitting in the truck.

I was pleased to see that TFS integration made the top ten list of new features in Expression Blend 3 (see here).  You will need to get a patch (KB967483) to Team Foundation 2008 for the integration to work.

Rollback\Undo Disks

When you roll back to a snap shot or undo your session changes (with Virtual PC undo disks) the version of the files you have on disk can be different than the version that TFS thinks you have.  Here is a worse case scenario:

1. User gets version 1 of foo.cs – takes snap shot of VPC/Hyper-V
2. A month passes.  User gets latest foo.cs which is version 20
3. User rolls back VPC/Hyper-V to snap shot in step 1.  Server still thinks user has version 20.
4. User pends a change on foo.cs and checks in.   All changes in foo.cs that occurred between version 1 and 20 are lost since the server thinks user had the latest version (20) and thinks user deleted those changes with the check-in.

Similarly, if you replace step 4 with a normal get latest foo.cs will not be updated since the server thinks you have the latest version 20 already, which you don't.

What to do if you need to roll back \ undo your virtualized client

Use the Force -  To get the server and workspace versions in sync again perform a get using the force option. 

OR

If you are using Hyper-V a better solution is to put your workspace on a drive that is offline to the host OS (Windows 2008) but known to the Hyper-V machine.  You have to disassociate this offline drive from the Hyper-V machine before you do the rollback and re-attach afterwards.  This keeps the rollback from affecting the workspace drive, leaving your workspace files the same. 

Conclusion

You can enjoy the benefits of client virtualization and TFS Version Control by keeping in mind the impact of rolling back \undoing disks have on your TFS workspace.  A simple post roll back step or putting your workspace on an offline hard drive (for Hyper-V users) is all you need to do.

We have just shipped Team System Web Access (TSWA) 2008 SP1 Power Tool.

· Download TSWA 2008 SP1

What’s New in TSWA 2008 SP1?

· Work item only view for users without a client access license. [Previously known as Work Item Web Access (WIWA) feature]

· Run a single instance with multiple languages (*)

· Create work items with initial values by using a URL.

· Share ad-hoc work item queries by using a URL.

· Find and view Shelvesets - great for code reviews.

· Improved work item search syntax.

(*) Single instance with multiple languages

A single instance of TSWA now supports multiple languages. By default, the UI language is based on the user's browser settings (accept-language header). The UI language can be overwritten in profile settings. In total, 10 languages are available: English, Chinese Simplified, Chinese Traditional, German, French, Italian, Japanese, Korean, Russian, and Spanish.

Chandru Ramakrishnan, a TFS Version Control Platform developer who keeps our internal dogfood server humming, noticed this morning that our internal TFS Version Control dogfood server has over 1 billion rows for local versions.  That is over 1 billion files/folders served to internally!

Find In Source Control

From the Source Control Explorer you can right click on a folder and chose Find In Source Control.  There is a sub menu containing Status search, wildcard search, and changeset.  Below is a screen shot from a status search of all checked out *.cs files under $/Orcas/Migration:

This search shows all users that have files checked out under the specified path along with with the workspace and machine (shown between the []) name where the pending changes exist.   From this view you can checkout files, undo changes (including someone else's changes if you have permission), view history, open the file (double click), and open the folder in Source Control Explorer.

Quick Label

The labeling functionality in TFS is very powerful, but sometimes you just want to create a quick simple label on a folder.  Quick label does that.

Open in Windows Explorer

Have you ever wanted to open Source Control Explorer's currently selected folder in Windows Explorer?  Now you can by selecting a folder that is mapped locally, right click, and choose Windows Explorer.

Team Build Notification

Now you can be notified on your desktop by a tray application when a Team Build of interest has been queued, started, or finished.  This has been a highly requested feature that we are happy to deliver in this power tool release.

The Build Notification Application will pop up a "toast" message when build status changes.  Below is an example of what you would see when the build is broken.

...and much more....

• Additional TFPT.EXE commands for configuring Team Explorer connection settings (tweakui) and for destroying Work Items and Work Items Type Definitions (destroyWI, destroyWITD).
• Updates to the TFS Best Practices Analyzer for use with a Team Foundation Server 2008 deployments.
• The Process Editor is updated for use with Microsoft Visual Studio Team System 2008. It also has several improvements, including: performance improvements, improved discoverability and bug fixes.

You can discuss TFS Power Tools here or report bugs here.

Enjoy!