Sunday, December 21, 2008

Holiday release of branching guide for TFS

In case you missed the full announcement (at Jeff Beehler’s blog), I’d put a line about it too.

New version of TFS Branching Guide is released at CodePlex! In addition to what Jeff already blogged about,  three highlights of this version are (in my opinion):

  • It provides new content (especially in main and scenario sections) based on real-world TFS implementations
  • It breaks the content into easily consumable parts (my favorite are Q&A and scenarios), thus opening the way for more updates in the future
  • There is change of the direction in v2 for how to handle community involvement. V2 document is purported to be a “live” document – that is community is welcome to contribute into this document (this is part of the reason why it is released in several distinct sub-documents). The way to contribute or influence the document is to use CodePlex infrastructure and file work item for it (make sure to specify the section of the document)

Also at this note, I would like to wish everybody Merry Xmas, Happy New Year, Festivus and happy holidays at large! See you in 2009!

Sunday, December 14, 2008

Word about task-driven configuration management

Recently I read an interesting post that attempts to explain how configuration management process has evolved from “file-based” into “task-based”; and am writing mine as some of the opinions expressed there are arguable.

First of all, the concept of task/feature/change request artifact associated with the changes to code is not new; first commercial CM system, CCC Harvest (dating from mid-70s) already employed this concept; and the current version of the software is still built around such artifacts. Thus the idea of configuration management process driven by the change artifacts rather than by the changes in code files is every bit as traditional.

Another misconception is that configuration management using files-based version control alone is simplistic as compared with task-driven CM. Branch/merge model, labels (snapshots etc.), concurrent check out and other concepts that are file-based provide for pretty flexible environment, and many of the tasks attributed to task-driven tools are achievable (as illustrated, for example, by Perforce). 

But it is certainly intriguing how nowadays for most CM tools the integration with meta-data artifacts other than files (however they are called - tasks, CRs, defects etc.) became one of the most important and requested features.

Personally, I have a theory that tasks-driven approach become more popular due to the changes in the way software development is done. While task-driven process was available for years, usually it was an integral part of a rigidly formal structure. The distance between defect filed by the customer support and developer who handled the bug was huge and involved multiple tiers, and smaller shops just did not have the resources required for such multi-tier formalized setup.

But in recent years, development become more and more “agile” (for the lack of better term), and the “path” between code and related artifacts become significantly shorter. And the process itself changed as well – perhaps that’s why the tools that worked well for enterprise in the past (CCC Harvest or IBM Rational ClearCase/ClearQuest) find it increasingly difficult to compete with less formal and more flexible competitors. Microsoft Team Foundation Server is a good example of the tool that can fit into enterprise environment but is still sufficiently agile to be a valid choice for less formal one.

There are some things in TFS that you can achieve by using work items in conjunction with source controlled files:

  • Associate work items with checked in files (and enforce the association using check-in policy); that way every set of checked in files has bug, task, change request etc. aligned with it
  • Establish what work items are contained in specific build (based on changesets contained, work item – changeset associations and build labels)

However, there are things that are not available (out of the box), for example

  • Merge changed files from branch to branch based on work items
  • Get file versions based on work items (f.e. get me versions associated with bug fixes X, Y and Z)
  • Partition file revisions according to the work items state

Important as they are, the missing features hardly pose insurmountable obstacle in TFS adoption (of course, unless you hit some political snags along the way – you know, of the kind “if X is not supported exactly in the way I want it, we are not buying it”). If you believe otherwise, I would be very interested to hear about it.

Tuesday, December 09, 2008

Do you get Git?

In the spirit of providing links instead of content, here is another link – comparison of Git with other source control systems popular in OSS world.

And if you do not know what Git is, it is well worth a look (perhaps that comparison will excite you enough to have a look).

Everything you wanted to know about locks in TFS

I rarely point to links, trying to stick to content instead, but this time I’ll redirect you to an excellent post by Philip Kelley, a developer on TFS VC team. The article nicely summarizes many little known facts related to locking in TFS, such as why locks are not retained in shelvesets, how lock on folder differs from recursive lock on every file and so on. 

Monday, December 01, 2008

Case of never ending unit tests

Couple of days ago I came across very weird issue on my new box – unit tests that were started (either from within Visual Studio or using MSTest command-line) would never complete. Test run would just hang pending forever.

Since I was running latest and greatest VS2008 with SP1, I have started blaming permissions first, and then new Windows bugs (since I was running Windows 7 build), and that did not help (does it ever?).

As it turned out, the problem was my computer name. It was all lower case (upper case does not exhibit the problem), and somehow that prevented unit tests run from ever completing (even without any TFS stuff – just plain unit tests). The workaround is to change the computer name (either using Computer->Properties, or by tweaking the registry if you cannot do it [for example, when computer is joined to a domain]). The steps are described in this helpful MSDN post.

Thanks for the workaround go to Ed Hintz.