Adam Singer : TFS Version Control

He who permissions least, permissions best

Adam Singer — Wed, 23 May 2007 21:05:00 GMT

I've heard a few questions and comments about our permission model recently. For example, some folks have asked why user in two groups, one granted a permission and one denied the same permission, is denied the permission rather than granted it. The answer lies in our permissioning model.

Lets first define a few terms to get us all on the same page. Note that these are not necessarily official terms, they're just the terms I've used when discussing permissions with folks on the team here:

Identity: A user or group that may be used with the permission system. Groups are both external groups (e.g. active directory security groups) and TFS groups (e.g. [SERVER]\Team Foundation Administrators)
Securable object: An item in Team Foundation which may have permission rights granted or denied to perform certain operations with the object. Examples are the folders and files stored in Version Control, Area nodes, Projects, and the Team Foundation Server itself.
Explicit vs. Implicit: An explicit perimission for a given identity is assigned directly to that identity, while an implicit permission is assigned to a group the identity is a member of (either direct membership or through nested membership)
Inherited vs. Immediate: While Team Foundation Server global and project permissions don't have a notion of inheritence, permissions on items stored in Version Control do. An inherited permission is assigned to one of the parents of a given securable object, while an immediate permission is set on the securable object itself.

Overall, we follow the same permissioning scheme as the Windows OS. A permission may be allowed, denied, or unset. Unless a permission is allowed (explicitly or implicitly, through inheritence or immediately on the securable object), the permission is denied. The only exception is for Administrator users who are always granted permissions (for Version Control, admin users are users who are Machine Administrators on the AT). Hence, if you don't want users to be able to be able to perform a given action, simply don't grant them permission to do so and don't add them to a group that's been granted that permission.

From that notion comes the title of this post- keep your permission set as minimal as possible, and you won't run into situations where a user is a member of 27 groups, half of which are granted some set of permissions, half of which are denied some overlapping set, and all of which cause your head to spin.

Now, that's not to say that you shouldn't set permissions on objects. Certain permissions are necessary to use the system in a reasonable way. Just remember that as soon as a user is denied a permision, whether explicitly or implicitly and whether the permission is inherited or immediate, no amount of grants at any level to any group will override the deny setting. Denied permissions are the trump card and should be used to specifically lock resources and components. Since all denies trump all allows aside from administrator status, users may be unable to perform actions if they're in two groups that have different permission settings.

Let's walk through a simple example. Suppose you have four different groups- developers, testers, contractor developers, and contractor testers. Due to corporate policy, contractor developers may be disallowed from directly checking in changes and locking files, while contractor testers may be disallowed from viewing the developer source code. Lets also suppose that the two contractor groups have been added to the other two groups (contractor developers to developers and contractor testers to testers). If your product code resides under the Version Control path $/AcmeCode/Product/, you could set permissions on the folder as follows:

allow the "developers" group read, label, lock, pendchange, and checkin access
deny the "contract developers" group checkin and lock access
allow the "testers" group read access
deny the "contract testers" group read access

All other permissions (e.g. "Undo other users changes") are unset for all four of these groups, so are treated as denied permissions unless the users are members of other groups. This permission set will completely lock out the "contract testers" group from that version control path, while the "contract developers" can read, label, and pend changes which they will then shelve to have a full developer check in.

An alternate method would be to make the developers group a member of the contractor developers group (and not vice versa, only granting the "contractor developers" read, label, and pendchange permission while adding the lock and checkin permissions to the developer group. Of course, this seems a little weird from the perspective of someone looking at group containment and could therefore get confusing.

So, that's a little long winded, but I hope it gets the point across and helps you make informed decisions about what our permissions mean.

Open and Switch Case

Adam Singer — Tue, 29 Aug 2006 20:15:00 GMT

A few folks on the forums have asked how they can specify other editors to open files in Team Foundation version control. In particular, Acrobat PDF files have come up a few times. When investigating the issue, I discovered a workaround that I thought might be of general interest.

To open a single file with a particular application:

Highlight the item in Solution Explorer
Select the "View" --> "Open With..." menu option
Choose one of the default applications, or click "Add..." to choose a different application
Click "OK" to open the document

To set an application as the default for all files with a particular extension, follow the above instructions, adding a step "3a" to click the "Set as Default" button. Afterwards, when you open items from Source Control Explorer, they will use the specified applicaiton, as well.

What you wish for

Adam Singer — Fri, 26 May 2006 21:10:00 GMT

As I depart the Version Control team, I'd like to make one final note about a particular request we've heard often. Many folks want us to get the latest version of a file when they check it out for editing. On the surface, this does seem like a good idea. However, I'll try to explain here why you don't really want what you think you want.

Let's examine a few simple timelines.

Timeline 1: Single file edit

In the simple case, let's say you have two developers: Alice and Bob. After some changeset, let's say 10, both users have the latest version of all files. Alice checks out file "Program.cs", makes a change, and checks in to create changeset 11. Bob then tries to check out Program.cs. In the current implementation, he has the changeset 10 version of Program.cs, not the changeset 11 version, and will have to merge his changes with Alice's when he checks in changeset 12. The merge may not be very difficult, or it might have many conflicts, but Bob is eventually able to perform the integration, (re)run any necessary tests since he's now integrated Alice's changes, and then check in.

Timeline 2: Multiple file edit

Now, let's get a little more complicated. Alice checks out both Program.cs and MainWindow.cs, edits them, and checks in to create changeset 11. Alice may have actually changed the APIs between Program.cs and MainWindow.cs or she may just have modified some of the internal functionality in each. Again, afterwards, Bob tries to edit Program.cs. He still only has the changeset 10 version, so will have to merge his changes when he checks in changeset 12. Seeing the resolve dialog when he tries to check in warns him "somebody else made a change!"

If, however, Team Foundation Version Control silently performed a get operation to bring Program.cs up to changeset 11, Bob's workspace would have mismatched versions of Program.cs and MainWindow.cs. Suppose that one of Alice's changes in Program.cs relied on a change in MainWindow.cs - Bob's new code in Program.cs assumes the old MainWindow.cs behavior, and now when he checks in Program.cs itself is in a bad state. In the case of API change, on the other hand, Bob's project just went from building successfully to not building at all even though he hasn't even made his changes yet. If poor Bob doesn't try to build until after making his changes, he's then under the impression that his code changes broke the build rather than the automatic "Get Latest on Checkout" that TFVC performed.

That's pretty lame, no? Poor old Bob now has a headache and he has to track down the cause of the build break. And when he finally figures it out, he then may run another get latest manually, picking up Cheri's changeset 12 and Daniel's changeset 13, each of which may conflict with Bob's existing pending changes and/or have other dependencies to worry about. We've just turned the snowball into an avalanche. If Bob was three files into a six file fix, he's now forced to deal with integrating other people's changes when what he really wanted to do was finish making his changes. Without the forced Get Latest on Checkout, Bob would have been able to have two separate phases for "make the fix" and "integrate with other people's changes".

Timeline 3: Concurrent file edit

As hairy as that scenario got, let's take it one step further and see why the fix doesn't actually avoid the problem. Suppose that we actually do have the Get Latest on Checkout in place. At changeset 10, Alice and Bob have the latest version. Then, both users check out Program.cs for editing. Since they both have the latest version, nothing is done to update their workspaces. Alice checks in changeset 11, and then Bob tries to check in changeset 12. Bob still has to perform a merge of his changes with Alices even though we added the extra capability.

Therefore, by adding this capability to TFVC we've not only introduced other potential mid-fix merge issues, but we've also failed to fully resolve the original problem since Bob will still have to perform a merge operation prior to checkin.

In practice, I've found that the files I don't have the latest version of when I check out are just a few of the shared helpers and central infrastructure. These are the components that are most likely to hit the "Bob checks out before Alice checks in" scenario anyway since many people might be making minor changes at any given time. If even one of them checks in a change after you began editing you'll have to merge when you try to checkin and you haven't saved any effort with the extra step of Get Latest on Checkout.

Therefore, even though it's been one of the most asked-for features, I don't think the users who think they want it actually want it. Most likely, it will still get added, just like you can disable multiple checkout for a project - not generally a good idea IMHO, but it's there. I'd also like to say that, though I'm certainly far from a merge guru, I've come to stop fearing the three-way-merge process. It's actually quite simple and generally all of the work other than clicking "Auto Merge All" is done for you.

In conclusion, be careful what you wish for. You just might get it.

The CAT-5's out of the Bag

Adam Singer — Wed, 05 Apr 2006 20:09:00 GMT

I'm sure many of you have read Eric Sink's "Four Questions". If you haven't though, I highly recommend it. [Thanks due to Martin Woodward for linking to the post!]

Now that we've shipped version one of Team Foundation Server, we've started getting a lot more feedback. It's great to see that so many people are interested in trying out the new toolset, and it's helped us learn what the "real world" use scenarios are like. What I've seen so far is that we weren't too far off on our core use test areas, though some of the complex combinations weren't tested as thoroughly. There haven't been any big surprises, which is a relief.

Still, life continues and we're planning ahead regarding how we can make the product even better. I'm curious to know what your top pet peeves are with the current system, Version Control or otherwise. What can't you do that you'd like to? What works differently than how you expected? What snags have you hit that impact productivity? Are there any other problems you've found? How much wood would a woodchuck chuck if a woodchuck could chuck wood?

And remember, there are 10 types of people in the world:

Those who understand binary numbers.
Those who don't.

I'm inclined to believe these groups map pretty well onto Eric's groups, but would be happy to hear arguments to the contrary.

Recursion: It's what's for dinner

Adam Singer — Fri, 17 Mar 2006 01:53:00 GMT

Silly though it may be, have you heard that James Manning posted that Buck Hodges posted about Rob Caron talking about Rick LaPlante's public announcement at SD West that Team Foundation Server ships tomorrow?

On behalf of the Version Control QA Team, I'd like to offer a hearty:

SHIP IT!

[N]TFS and Alternate Data Streams

Adam Singer — Thu, 16 Mar 2006 22:57:00 GMT

Perhaps you've heard of them. Files in NTFS may have multiple "Alternate Data Streams" (ADS), each with its own contents. It's an interesting concept, certainly, but one that requires all software written for NTFS to buy into it, which is always risky. For example, lets say we try:

C:\>echo a > foo.txt C:\>echo b > foo.txt:bar C:\>type foo.txt a C:\>type foo.txt:bar The filename, directory name, or volume label syntax is incorrect.

Note that type doesn't know to look for the extra stream. Still, we can see it by running:

C:\>more < foo.txt:bar b

Now, suppose we want to edit the file. Let's say we're a big time DOS fan, and we still like edit:

C:\>edit foo.txt

Let's change the first line to "a2" and then save and quit. Now, let's see what happened to our extra data stream:

C:\>more < foo.txt:bar The system cannot find the file specified.

It's gone! Suffice it to say, this is less than ideal.

So, you may be wondering, what does this have to do with Visual Studio's Team Foundation Server Version Control? Well, let's give it a go:

echo a > file.cs echo b > file.cs:bar tf add file.cs tf checkin /i tf get file.cs /force more < file.cs:bar

Looks like the alternate data stream is gone. This is by design- we made the decision early on not to support ADS. One side effect is that if you've set metadata information on the "Properties" -> "Summary" page, this data will be lost upon checkin. Note, however, that this is not true for files like Microsoft Word .doc format for which this data is actually a part of the file itself rather than an ADS.

CLR and Present Danger

Adam Singer — Mon, 06 Mar 2006 21:51:00 GMT

Jeff Maxton recently pointed out an issue with Team Foundation and the Windows folder "encrypt contents" option. Briefly, the problem is this. Suppose you want to encrypt your working folders for your Team Foundation workspace. Theoretically, you should...(read more)

Test Team vs. The Matrix: Fight!

Adam Singer — Thu, 19 Jan 2006 18:37:00 GMT

For the past few weeks, we've been running our Full Automation Run (FAR) against several dozen different Team Foundation Server configurations. We've tested everything from Workgroups to VPCs, Chinese to Turkish, IPv6 to 64bit machines. We reverently call the spreadsheet of test configurations "The Matrix", and The Matrix definitely has us...

It's very interesting how testcode that worked fine on English product/English OS in a domain environment needed to be tweaked to pass as expected on other configurations. Two of the most interesting issues we've dealt with are as follows.

In our Workgroup environment, usernames are in the form [AppTierMachineName]\joeblogs. Since we'd originally used System.Windows.Forms.SystemInformation.UserDomainName on the client to get the domain name, our "UserFullName" would be [ClientMachineName]\joeblogs and any output that expected full name would fail. The workaround turned out to be more difficult than just dropping in the AT Machine name, since many of our test runs have two AppTiers. We need to first determine which server we're executing against, and then find its name. At the same time, we don't want to always make this change since we still have to run automation in Domain environments. The fix turned out to be a bit of a headache to piece together, but should now cover all the bases.

The second issue occurred in non-English product FARs. We load the localized resource strings as part of each testcase so we can properly match expected to actual output. However, not all resources are localized. Some, such as "{0}: {1}" (also known as "AColonB") are only found in the default Neutral Language Resources. Therefore, we had to load both the neutral resources dll and the localized resource dll from two separate files. To do this, we'd been using Assembly.LoadFile for quite some time. We also used a testcode method on the GUI resource strings to convert them from resources to actual expected values. However, the combination of these two only gave us English (i.e. Neutral) resources and so tests were failing left and right. It kind of made us feel like Neo during the fight scene in Matrix: Reloaded where Neo battled dozens of Agent Smiths. Turns out that LoadFile was the culprit- in 2.0, LoadFile doesn't really do what you wanted it to. After making the three character change, our pass rates skyrocketed.

While it's definitely confidence inspiring product-wise to discover that a test failure is due to test code rather than the product code, it's good to see more recent test runs experiencing fewer and fewer of these issues as we prepare to sign-off on the RC soon.

Notable

Adam Singer — Thu, 01 Dec 2005 20:31:00 GMT

After a bit of revising and internal processing, I'm the proud author of two TechNotes! Both are topics I've posted here before, but if you'd like to see them in their next stage of evolution, here they are:

TN_1700: Which Team Foundation commands need to be checked in?
TN_1701: How do Team Foundation Source Control locks and permissions differ?

Check the TechNote page for more excellent resources on Team System, as well. You may want to bookmark, too, as I've heard there are quite a few more notes in the works.

Looking at the world through rose-colored versionspecs

Adam Singer — Tue, 29 Nov 2005 01:10:00 GMT

James' post on the DateTime versionspec reminded me that I wanted to post a brief summary of versionspecs in Visual Studio Team Foundation's Version Control.

There are 5 different flavors of version specifications, each with its own syntax. Their one letter identifiers from the command line are ‘T’ for ‘tip’, ‘C’ for ‘changeset’, ‘D’ for ‘date’, ‘L’ for label’, and ‘W’ for ‘workspace’. For the purposes of our discussion, let's suppose we've got a server with a single solution named "Galactic Explorer" containing a file originally named "MyFile.cs". This file may have been edited, renamed, deleted, undeleted, branched, merged, etc. Let's say it's been changed in changesets 307 (add), 310 (edit), 311 (rename to aFile.cs), 312 (rename to AFile.cs), 317 (delete), and 319 (undelete and rename to OldFile.cs). In particular, here's a snapshot of this History dialog on this particular file. How can we access a particular version of this file? Why, by using our handy versionspecs!

First and foremost, we have the "Tip" version specification. This is also called "Latest" in the UI. This versionspec indicates that we want to work with the most recent version of the file in the server. In the case of OldFile.cs, that would equate to changeset number 319. From the command line, we could say "tf get OldFile.cs;T" in order to retrieve the latest version of the file. If you don't specify a versionspec, "T" is assumed. Where this comes in handy, though, is if you want to compare another version to the latest: "tf diff MyFile.cs;C314~T". What's the "C314"? Well...

Changesets, as I've mentioned before, are atomic groups of changes applied to files on the server. The changeset numbers are monotonically increasing and always increment by 1 from one change to the next. Each changeset number is unique among all changes on a given server, even if the affected items are in different team projects. When you specify a changeset versionspec, the server looks for the version of the item that existed when that changeset was checked in. In this case, if we specify changeset 314 of OldFile.cs (e.g. “tf get OldFile.cs;C314”), we’ll get the version that was checked in with changeset 312. It's also important to note that this is the default if you don't specify a letter-- "tf get OldFile;C314" is the same as "tf get OldFile.cs;314".

Another way to specify an exact point in time is with the date versionspec. Since changesets occur at a single point in time, using the date version spec maps to the last changeset submitted before the specified time. For more, read James’ post here.

Labels are basically a collection of item/version pairs. A label may contain an arbitrary set of items on the server, and exist within a certain folder's scope. Users specify which version of the items to label when they apply the label to each specific item. For more on labels, check here. One important thing to note about label versionspecs is that any item not labeled will be considered as non-existent for the purposes of that command. For example, let’s say we have a label “MyLabel” applied to version C312 of OldFile.cs, among other files. Another file in the folder, “OtherFile.cs”, is not labeled by MyLabel but existed in changeset 312. Suppose we run get in that directory: “tf get * /version:LMyLabel”. We’ll see something like this:

D:\Galactic Explorer\Galactic Explorer: Replacing AFile.cs (moved from D:\Galactic Explorer\Galactic Explorer\OldFile.cs) Deleting D:\Galactic Explorer\Galactic Explorer\OtherFile.cs

What happened? We got the pre-rename version of OldFile.cs. Then, the server noted that we’d asked for the version of OtherFile.cs in the label MyLabel. Since no such version exists, it removed the file. Thus, you can specifically exclude certain files from certain operations. This is important for consistency of our commands, as well. If you say "tf get OldFile.cs;C20", we'll remove the file from disk since it didn't exist in that version. The same goes for C317 and C318 since the file was deleted during those changesets.

Lastly, there are workspace versions. At first glance, this may seem somewhat silly. Workspace version indicates the version last gotten in a particular workspace. Hence, if you simply say “tf get * /r /version:W”, you’re telling the server to download the last version you downloaded. This should never do anything, though you can add the "/force" flag to redownload. However, you can append a different workspace here, such as "tf get */r /version:WMyOtherWorkspace" to get the same version in the current workspace as you have in another of your workspaces. Suppose that a coworker has found a bug and you want to reproduce it under a debugger. You can run “tf get * /r /version:WTheirWorkspace;DOMAIN\Coworker” to get the last version of the code which they downloaded. This is also handy for buddy testing before you unshelve someone else’s changes if you want to have the same setup that they have.

I hope that helps clear things up a bit. Personally, I’m most likely to use tip, changeset, and date, though I have used the workspace version a few times.

Twelve Step Programs

Adam Singer — Mon, 14 Nov 2005 16:00:00 GMT

Over the past few weeks, I've set up several Visual Studio Team Foundation Servers. Granted, this is something I've done a few dozen times since I first arrived, but I feel like I'm starting to get this down to a science. In any case, I wanted to post my own personal 12 steps to getting a combined ATDT set up. It usually takes me about 4 hours, but then I'm also doing other things on my main machine at the same time.

Setting up an ATDT Team Foundation Server:
1) Reimage my machine to saved image of Win2003 SP1 with Office installed
2) Run Microsoft Update
3) Create new image with latest patches
4) Check e-mail, search net for new wallpapers, erase whiteboard, check e-mail, water bamboo plant, reorganize bookshelf, check e-mail
5) Restart and join machine to Domain
6) Install IIS 6.0:
- Make sure Frontpage Server Extensions are *not* checked
7) Install SQL Server 2005
- Select all components
- Use the Default instance
- Use Local System account rather than a named account; at the bottom of the screen which asks you to select a user, check all boxes so that all services start automatically
- Use Windows Authentication
- Select the default collation and configuration options
7a) If developer edition- open Sql Server Surface Area Configuration Manager.
- Open Surface Area Configuration for Services and Connections
- Make sure Analysis Services and Database Services both allow local and remote connections. If not, set them to and then restart all SQL components (via SQL Server Configuration Manager)
8) Install Windows Sharepoint Services SP2
- Use Server Farm
9) Rerun Windows Update
10) Run ATDT installation
- Use two different users for service account and report account
- Choose to send out reports via an smtp server with reply address as the service account
11) Install the Team Foundation Client (Team Explorer)
- Run PCW to create a scratch Team Project
- Run PCW again to create normal Team Project used by our automated tests
- Add users to the project and server groups, as desired
12) Test new setup by asking some hapless coworker to "try this out real quick".

Works like a charm every time. I switch hapless coworkers on a dual-rotating basis to keep them guessing, though.

My voice is my passport

Adam Singer — Mon, 07 Nov 2005 23:03:00 GMT

Locks vs. Permissions

Visual Studio's Team Foundation Version Control has a very powerful access control model, permitting administrators to grant groups and individuals only the specific capabilities they need to do get the job done. Team Foundation provides two ways to control the abilities of authenticated users to use version control. You can either temporarily lock items or permanently set the users’ permissions. While both of these methods can be used to achieve some of the same ends, it’s often preferable to use one over the other.

This is a brief overview of how these two access control mechanisms work to help you decide what’s best for you. We’ll first review the basics and then investigate the areas where they overlap. Specifics may vary depending on particular infrastructure, but there a few general guidelines to follow.

Locking

Locks can be placed on any version control item stored on the Team Foundation Server. If the lock is on a folder, it is implicitly recursive and thus applies to all sub-folders and files. Locks are considered “pending changes”, though they behave slightly differently from other pending changes. Instead of becoming active when checked in, they are active until checked in or undone. Therefore, they are a quick and temporary way to prevent others from changing items on the server.

Types of locks

There are two types of locks- check-in and check-out. Check-in locks prevent other users from checking in pending changes on the locked items, while check-out locks prevent people from pending changes at all. If other users already have pending changes on an item, you cannot lock that item for check-out. In this sense, a check-out lock is more powerful than a check-in lock since it prevents users both from pending changes and checking them in rather than just the latter.

Locking rules

When locking a version control item, a few values are checked to make sure the lock can be set. First, users may only lock an item if they have the “Lock” permission on it. In addition, only one lock may apply to a given item at a time. Since this also applies to recursive locks, a user may not lock an item whose parent is locked by someone else. Conversely, a folder cannot be locked by someone if another user has a lock on a child of the folder.

Permissions

Permissions define the actions that groups and individuals are allowed to enact on the Team Foundation Server. It’s important to note that permissions are associated with items, though not with a particular version thereof. For example, if there are three versions of a file, there is no way to grant a user read access to only the first two.

Global vs. Item

There are two types of permissions. Some apply to the whole system, while others affect individual files and folders. These are “global” and “item” permissions, respectively. Item permissions may be inherited, and generally are by default. However, you may tell an item not to inherit permission. You may also override inherited permissions by explicitly setting them on a given item.

Setting permissions

Permissions take effect as soon as they are set, and remain in effect until they are changed. Of course, as mentioned above, permissions apply to all versions of the affected items. This does not undo actions which have already occurred, however. This applies both to global permissions and item permissions. Pending changes on an item are not undone if a user loses the PendChange permission. If a user makes a workspace while they have the “CreateWorkspace” permission, their workspace does not disappear if they later lose this permission. They may continue to use the workspace as long as they have appropriate permission to access the server.

Preventing change

There are two permissions in particular which allow users to change items on the server. The first is “PendChange” which allows users to add, branch, edit, merge, rename, delete, and undelete items. The second is “Checkin” which allows the users to check in the changes they pended.

Head to Head

So, let’s review some of the important differences:

	Lock	Permission
Duration	Until check in	Until changed
Can turn off inheritance	No	Yes
Per-user access control	No	Yes
Restore previous state with Undo (or unlock to keep other changes)	Yes	No
Can be set with current pending changes	No for “check-out”, Yes for “check-in”	Yes
Prevent new changes	Yes for “check-out”, No for “check-in”	Yes

What does this mean for you? Well, here are a few examples:

1) Joe Developer is working on a hot fix for an important customer. While working on the task, he locks the relevant files for check-in to make sure that no one else checks in changes to the infrastructure until after his fix has gone in. When he checks in the files, they become unlocked and other users can get the new version to merge their changes and check in.

2) The Ajax Company has hired a few summer interns. While they begin to learn the ropes, they’re required to pass all of their code to a full time employee for verification and checkin. The admin denies the group “Summer Interns” the Checkin permission on the whole tree. Instead, they can pend changes, shelve them, and then ask a coworker to unshelve them for review.

3) Sally Architect needs to make some overarching changes which she knows will be difficult to merge with other changes. She locks the items for check-out to prevent anyone else from modifying these classes (since merging with Sally’s changes would be a headache). When she checks her changes in, users may once again pend changes on those items.

4) Product Foo has just entered version 2, and the previous version has been branched to a separate folder. On the version 1 branch, the admins turn off inheriting permissions and only allow individual users the PendChange and Checkin permissions as needed for hot fixes.

These are just a few examples of when each type of access control is useful. Though we could achieve similar behavior with either, each is particularly tailored for certain types of situations.

The Origin of the Specs

Adam Singer — Wed, 12 Oct 2005 02:02:00 GMT

According to Wikipedia, there are over 800,000 species of insect, only 82,000 of which are "true bugs". The same sort of thing can be said about work items in Visual Studio Team System if you drop a few orders of magnitude. Here's a quick note on the evolution of work items within our dogfood system.

When I first arrived here a little over a year ago, we used our dogfood Team Foundation Server pretty much exclusively for product bugs. Some time after around the start of the new year, there were the occasional 'Task' or 'Scenario' items thrown into the mix. The tasks mostly described non-developer deliverables, such as "prepare automated test runs to run as normal user." Scenarios were used to track the quality of a particular feature (it's "Overall Gut Feel", or OGF). Even so, the mix was still highly in favor of bugs by a ratio of fifty to one.

Over the duration of the Beta 2 final test passes, the ratio jumped to only ten to one, and included the new "Test Task" specifically designed to help track QA work such as test infrastructure, automation, and test planning. Then, through the start of summer, the ratio tilted wildly and showed only about two bugs for every three non-bug items. We were doing extensive testplanning, test automation development, and other "behind the scenes" work here on the test team, and really started to take full advantage of the Team Foundation work item system.

Since then, we've settled back to about a ten to one ratio as we've intermingled intense test passes with test development. Looking through the mix on my plate, I currently have two test tasks (one on a test failure to investigate and one code review), seven OGF tracking items updated every few builds, and seven localized OGF items. I have the occasional active bug assigned back to me to verify a repro or fix, test task on new infrastructure to write, and other such tasks. It's a rare day that I don't start in by opening "My Active Work Items" to help plan my schedule.

The system really works, and has had the flexibility to track everything from the daily grind to the "big ticket" items. As a tester over on the Version Control team, I consider myself a moderately neutral observer, and I am definitely impressed.

Because it is not the sky

Adam Singer — Fri, 07 Oct 2005 19:50:00 GMT

We're testing the Japanese Beta3 version of Visual Studio Team System's Team Foundation Server. Of course, most of us don't actually know any Japanese, so we have to rely on computer translators to help us figure out what's going on. Not all of the translations come through as clearly as others, though. A few of my favorites are:

"[local path] because it is not the sky, it cannot delete" (for "[local path] cannot be deleted because it is not empty")

"There is no being less crowded territory which is sufficient for the disk." (for "There is not enough space available on disk")

"File MSBuild1.Proj is not found. It draws up newly?" (for "Cannot find the MSBuild1.proj file. Do you want to create a new file?")

"Label name 'test\test' is not effective" (for "The label name 'test\test' is not legal")

"Folder $/project/ClassLibrary1 is a possibility check out without of being done" (for "The folder $/project/ClassLibrary1 may not be checked out")

"There is no modification which is reset to the origin in the child of selective item or selective item" (for "There are no changes to undo in the selection or any children of the selection.")

"Mouth" (for "Mouse" control panel)

and, perhaps the most intriguing of all:

"Loose Gesture" (for the Microsoft "Paint" application)

Playing with Power

Adam Singer — Sat, 17 Sep 2005 00:57:00 GMT

As Chris says, we're very near the Beta 3 ship and the "ship it!" mantra is strong. We've done some pretty crazy testing during this test pass, including some of my current favorites- intentionally self-induced network connectivity issues, full disks, stopped services, misconfigured firewalls, and all the rest to simulate "real world" network noise.

I even got to test a bit with a computer that had hardware issues, though I didn't know it at the time. Apparently, it blew a few capacitors and needed its motherboard replaced. Quite the excitement trying to triage that one over the phone, let me tell you.

Overall, I just have to say that I'm really impressed with the vast improvements since Beta 2. Performance is through the roof, stability is up, bugs are down, processes are streamlined, and we're all really excited about the product we've put together.

After four weeks of hammering on this version, on a scale of 1 to 10, I rate it "SHIP IT!"