How to Find All Checked Out Files in TFS

Microsoft TFS provides a lot of nice integration with Visual Studio and a powerful command line environment for accessing the source control infrastructure.  Not as robust is the MSDN documentation.

A common need is to find out how to determine all the currently checked out files, and who they are checked out to, for a given project or solution.

As can be seen from the answers people gave here: there are a variety of interesting opinions on the subject.

But at the end of the day you don’t need any third party tools or janky UI to do it.  The command prompt will suffice.  My solution is described below:

First, open the Visual Studio Developer command prompt.

Execute the following command:

tf status $/MyFolder /user:* /recursive

The form being:

    tf status itemspec /user:username /recursive

The key is the /user:* parameter, which forces TFS to look at the server and determine all the checked out files in the path specified in the itemspec parameter. If you don’t use the wildcard you will only see files you personally have checked out.

For the specific use case, you would want to put this in a file versus to screen so it would look like this:

tf status $/MyFolder /user:* /recursive > c:\MyPendingCheckouts.txt

Note I ran this with VS2012 command prompt.

Tagged with:
Posted in SCM

Datepicker for Bootstrap with Twitter Bootstrap 3.0

Twitter Bootstrap 3.0 has significant changes to its CSS since the last major 2.x release.  Unfortunately a lot of components out there have not been updated to the new version and simply don’t work out of the box.  One of the more useful is “Datepicker for Bootstrap” (  This post describes the changes needed to make this work in 3.0.

1. Markup

This is the 2.x markup from the bootstrap-datepicker.js site:

<div class="input-append date" id="dp3" data-date="12-02-2012" data-date-format="dd-mm-yyyy">
<input class="span2" size="16" type="text" value="12-02-2012">
<span class="add-on"><i class="icon-th"></i></span>

In 3.0 things are a bit more tricky.  Here is the markup and I’ll walk through the changes:

<div class="form-group row">
<div class="col-xs-8">
<label class="control-label">Effective Date</label>
<div class="input-group date" id="dp3" data-date="12-02-2012" data-date-format="mm-dd-yyyy">
<input class="form-control" type="text" readonly="" value="12-02-2012">
<span class="input-group-addon"><i class="glyphicon glyphicon-calendar"></i></span>

So first the simple stuff.  The “icon-*” classes are replaced with “glyphicon” classes and in this case the relevant glyph is “glyphicon-calendar”.  The “add-on” class is now “input-group-addon”.

There are no longer “span*” classes.  Instead the “col-*-*” classes must be used.  But they cannot be applied effectively to an <input> element.  This is why the <div> is around the <label> and <input>.  It is also why we need the outer-div with the “form-group” class set. The  “form-control” class, which you need to use on the <input> tag, is 100% width.   Therefore the way to constrain is by limiting the size of the parent div.  In our examples “col-xs-8″ tells the div to use 8 columns of the 12 on all screen sizes (xs being the smallest, and the constraint is cascaded to the larger sizes automatically).  This means the <label> and <input> together will take about 66% of the screen.  In the 2.x CSS the span2 would render as 162px.

Note that although using the “row” class, and thereby the 3.0 form grid layout, is not absolutely necessary, you will save a lot of headaches by doing so.  I tried following the form-horizontal model at first but ran into some serious snags.  The responsive layout doesn’t play very nice when you try to set the <label> in one column and the <input> in another.  Because horizontal layout only works well at larger screen sizes, the lower screen sizes won’t get the “col-*-*” style applied.  So what ends up happening is the classes are dropped and the relative positioning becomes very ugly, with elements floating incorrectly, wrapping or even overlapping depending on your other markup.

OK but why do we care how wide the form control is? Why not just go with the 100% like all the other ones? Well, for datepicker-bootstrap.js we have a big issue with that. The datepicker control is bound to the “addon” component and positioned below and to the right of it. Therefore a 100% wide control will always put it off screen. Therefore 66% width is as big as you want to go. An alternative I played with is putting the “addon” component before the date field but it was not as intuitive.

2. CSS

Shew! The CSS is a lot easier. Basically just a few lines need to be changed in datepicker.css to refer to the new classes in Bootstrap 3.0 (which we have already used above).

So lines 176-187 are changed from this: .add-on i, .add-on i {

to this: .input-group-addon i, .input-group-addon i {

3. Javascript

Finally there is one Javascript change to datepicker-bootstrap.js.

Simply change the code on line 34 from this:

this.component ='.date') ? this.element.find('.add-on') : false;

to this:

this.component ='.date') ? this.element.find('.input-group-addon') : false;


Using the newer code from the changes are as follows:

CSS changes in datepicker.css on lines 446-447: .input-group-addon i, .input-group-addon i {

Javascript change in datepicker-bootstrap.js on line 46:

this.component ='.date') ? this.element.find('.input-group-addon, .btn') : false;

Finally, the JavaScript to enable the datepicker (with some options):

$("").datepicker({ autoclose: true, todayHighlight: true });

Tested with Bootstrap 3.0 and JQuery 1.9.1. Note that this fork is better to use than the other as it is more feature rich, has localization support and auto-positions the datepicker based on the control position and window size, avoiding the picker going off the screen which was a problem with the older version.

Tagged with: , , , ,
Posted in JQuery

Infinite Scalability?

I’m currently working on a very large system architecture problem focused on scalability in an environment with many unknown factors.  In the process of coming up with an ideal solution, I’ve been researching the latest literature on system scalability, talking to consultants and browsing the musings of the gurus.  Suffice it to say, there is a lot of dense architecture research on this topic and some divergence of opinion.

The interesting thing, though, is that the problem of how to address massive scalability has become urgent and commonplace in the Web 2.0 world of hyper-connectivity.  Take for instance Pinterest, the online pinboard site for the sharing of stylish ideas hugely popular with Gen-X women.  The site came out of beta in the summer of 2011.  As of this writing Pinterest is the 32nd most popular web property in the US with over 11 million pageviews per week.  Total pageviews having grown by over 120% in 3 months.  Yet the pages are able to be served up on average in 1.043 seconds (statistics from Alexa).

Clearly the Pinterest team has, thus far, figured out how to handle for massive scalability.  The thing is, unlike in the Web 1.0 world which many organizations are still stuck, any successful web property will have to grapple with how to scale in response to rapid and unpredictable growth.

In the paper “Life Beyond Distributed Transactions: An Apostate’s Opinion” (Helland,  2007) Pat Helland of describes a system architecture for a nearly infinitely scalable system.  The realization of Helland and many other have come to is that many of the tenants and sacred cows that many architects cling to for monolithic, limited usage applications simply do not hold true for massively scalable systems.  The lack of flexibility and modularity extant in traditional n-tier application design prevent systems from being able to dynamically scale to demand.

There is an increasing industry trend to respond to this by focusing on dynamically scalable infrastructure, so called Infrastructure as a Service (IaaS).  While this may solve problems in the short run, it is by no means a cost effective long term strategy.  The point being that without ensuring the application architecture as well as the data and infrastructure architectures are designed to scale, you will eventually hit a performance wall, but long before that you will likely hit a cost wall.

Udi Dahan put it most succinctly in a recent post on his blog:

Scalability is a multi-dimensional cost function, where part of an architects job is to figure out which dimensions are significant for the system/business, and what the expectation for growth is across each axis. (Dahan, 2011)

A non-trivial task to be sure, especially when massive increase in system demand corresponds with hitting business goals such as aggressive revenue targets.  But given today’s realities, solving this sort of problem should the core focus and value realization of systems architecture for any organization looking to leverage IT investment to its maximum potential.

Tagged with:
Posted in Scalability

Get every new post delivered to your Inbox.