Command Line TFS Access

There are a couple of useful powershell command-line tools that are of use:

This is useful to query tasks and work items

tfpt query “ProjectPath to query”

From a mapped folder allows the running of existing tfs work item queries from the command-line

It uses the current folders mapping to identify the project.

This is useful for quering checkins:

Run from the VS2012 command prompt:

tf history x:path_to_project /recursive /noprompt /user:”My User Name”

How to simulate a tfs build locally

When tfs is used as a build server it builds the visual studio projects differently to the way the IDE does.
Typically it will dump all of the build artifacts into a single folder (which breaks almost any post-build scripts).
However if you are building web applications it has a clever option that builds a useful web applications folder with everything that is needed to be deployed.
This happens for any web project where the output directory is redirected.

msbuild Whatever.sln /p:configuration=Release /p:OutDir=c:builds

This is useful when you have a web site project in visual studio 2010 (say a silverlight web project) that you would like to deploy but don’t have enough space on the build server to install the right tools.
This is quite powerful but would be useful if the documentation for this was more obvious.

Use of Version Control

In my opinion the use of version control is the definition of the professional programmer.

It forms one of the standard questions that I ask a prospective employer as part of the interview process (remember you are interviewing them as much as they are interviewing you).

I was listening to a recent DNR Show that covered Team System. In the show there was a discussion about version control systems and the use of branching.

Richard made a statement along the line of people should keep their branches for as short a time before merging.

I have been using Version Control in various forms for a number of years and have only had a single project where we needed to merge.  The majority of branches were long lived (although they would only change little from their branch point).

Branches in my experience are best used to provide bug fixes to a released version of a program when the current development version has moved along (and may not yet be sufficiently feature complete/tested to release as a replacement).  New development should be performed on the “tip” of the branch tree.  The checkpoint was taken when the build was released. Branches were only started when the first bug fix was required.  We would typically have 5 “live” branches per product.  New users would get the latest release, but some customers were reluctant to upgrade (especially Japanese Banks).

The only time that I worked on a development project that required branching was when we had two teams of developer trying to add significant distinct features to the same code-base.

Each team completed their development then a three-way merge was performed on the three branches (original, Team A and Team B).

Each of the version control systems that I have worked with has it’s own quirks.

I have worked in some places that just had a directory structure that was backed up weekly.  We used Beyond Compare to merge into the shared source and from it.

rcs is the simplest that I have used. It had a command line tool to check in and out.

mks source integrity added a gui to the rcs system.  It had a useful (yet slow) concept of a checkpoint. This formed an immovable label. You used checkpoints as the jump off point for a branch.  Since the storage was a file share it was possible to fix up errors easily, and it was also possible to move no-longer used code away to an archive yet keep the history. Labels could be slow to apply to a large codebase (one I worked on was ten years old).

pvcs has a nice concept of promotion groups.  Each file would have a promotion hierarchy (such as DEV, INT, BUILD, QA, RELEASE).  These would effectively be labels that had to be applied to revisions in an ascending order (all could be on the same file).  The idea is that you were free to check anything in at the DEV level – it had no guarantee’s even that it would build. INT was for passing to other developers, BUILD indicated that it at least compiled and satisfied rudimentary tests, QA was the next version to be released and RELEASE was production code.  You could check out all source at say BUILD then check out files locked to you at DEV over the top. This is a good way of checking that your code will not break the build before you promote it (to INT and then BUILD).  It encourages frequent check ins and integrations. You could easily replace the built-in compare and merge tools (my preference is Beyond Compare from scooter software).

starteam just seemed to work. It was limited with external tool integration.  It had nice features such as being able to get the source as it existed at a specified time.

svn is simple to use.  It integrates well into the windows desktop via TortoiseSVN.  You can even use svn bridge to allow you to use svn to store files in a tfs backend.  It was one of the earliest vcs systems to perform atomic commits – that is a group of files must all commit or the commit will fail.

TFS is a bit different to other version control systems (this is probably because it is relatively new – hopefully the nightmare that was sourcesafe has been forgotten) .  Firstly its the only vcs that actually remembers where that source has been checked out to (and objects if you move it without using the ide). It is highly integrated into Visual Studio (unless you use SvnBridge) which can make files that Visual Studio does not touch harder to configure (it can’t see changes to files copied at the file system level).  Is is also an atomic commit vcs – packaging code into change sets.  It is the only vcs that I know that does not allow pulling of a label (the excuses for this are rather weak – I don’t care that a label can be non-unique or moved, make a decision and pick the latest file version).  It is also lacking in macro support which is a very useful feature found in almost all older systems – macros allow you to include the version number/labels/commiter/timestamps from the checkin in the file when it is checked out.  It can also be a little odd when you ask it to “get latest” from within the IDE – it frequently fails to add new files.  It will ignore edited files when the latest source is grabbed – which is good since you don’t get your work clobbered by mistake.  It does have good integration support.

To be fair to TFS it is more than a vcs (but that is true of several of the others that I used) – it has an associated SharePoint site for task tracking among other things.

I probably need to explain why I am so down on TFS’s lack of macros.  In one project we used this feature to record the version number of each and every database object in a table.  The create scripts were separated into distinct files and I used a udf that was supplied a string that was populated by the filename and version.  This was really useful if you had a backup of a production database – you could immediately see how old the database objects were upon a restore.  This is not easy to implement without macro support.

VCS Nightmare

One place that I worked had an overseas development team that had entirely moved in from application support.  One application that they developed had an interesting naming conventions for sprocs. They would embed the version in the name: usp_MyProc_12_3.  This would be OK if they had bothered to replace all references but on a subsequent analysis of the database we found upto 5 different versions of the same proc in active use.  In addition they had been creating these customizations on each of three customer sites and did not always remember to bring the changes back so that it could be configured centrally.  It took us a while to recover the full source for that!

TFS Howler

TFS howler: password changes while VS is open – you lose the ability to check in until you restart VS.  Bug exists in 2005 and 2008
TFS is a very different version control system.   That is not a good thing.  It seems clunky and ill thought out.  Unfortunately I have to use it…

It assumes that you are using visual studio (unless you use the excellent tfs bridge/ tortoise svn).

You need to save everything before you can check in.

TFS fails as version control software

TFS is inadequate as a VCS.

The developers think that all development occurs in VS.NET.

This does not work if you use code generation


I have a spreadsheet that I was to control in VCS.

If I lock the file and then replace it I get a (false) claim that the file has not changed – which automatically unlocks the file.

In order to get the file checked in I need to edit another text file in Visual studio.  By changing this it notices that both have changed.


Why can’t it perform keyword expansion like every other modern vcs!