Maximum size of the file under source control - should you care?

In this forum thread I came across very interesting piece of information that I feel might be interesting to the community at large.

Probably anyone using source control application asked that question at some stage - what happens if I check in 500Mb disk image file? For some source control systems (f.e. VSS) the answer is relatively simple - you'd end up increasing your DB size by approximately 500 Mb every time you check in new revision of the file.
However, for TFS only deltas between the revisions will be saved, so your database will not become bloated if you store several versions of that huge binary file. Or so I thought - because it turned out that deltas mechanism is used only for the files that are smaller than 16 Mb. May be that's just me, but that number eluded me in the original documentation on MSDN and I was under the impression that if someone maintains several revisions of huge binary file it is not a big deal.

But in reality, that can well create a problem. In v 1.0 of TFS there is no permanent destroy, so if one created twenty revisions of CD image that will immediately affect your database size, and there is no way back!

The reason for this (conveniently explained by Richard Berg in the forum thread) is understandable - indeed, calculating deltas for large files can adversely affect server performance, and therefore it is disabled. But I am not sure that I like the way it is not specified in official documentation and not configurable on server.

Obvious way of making sure that your database is not affected by those binary files is not to store them in TFS at all (and create maximum file size check in policy to enforce the file sizes). Or if you do store them, store only one revision and use branches if you need to reference this file. While both approaches take some additional effort for policies enforcement and user education, at least now you can make sure you can explain that sudden increase in database size. Look for new revisions of those large files :)

TFS ripoff or back up your money (updated)

Today I come across pretty interesting post on MSDN forums. To give your some background: recently (about a month ago) some company started to market suite of products that supposedly perform migration from SVN to TFS, backup of TFS projects, work items etc.

The inability to backup separate projects has long plagued TFS community; the company was mentioned in several blogs and in several MSDN postings. I was saying to myself "Kudos to those guys for doing that enormous work and implementing functionality even MS itself was unable to implement". Until today somebody (apparently the buyer of the said software) posted the following:

"... is a fraud company. I had purchased one of their products. The buggers provided me a *** software, which was good for nothing. I have even heard from a mate of mine in France that they charged the product amount and never gave the product.

Today - Even their website does not work."

Well, that surely sets off some alarms. So I indulged a bit in some hobbyist investigation and here goes the list of interesting facts:

1. The company site is offline as of now; the domain was registered on April 19th, 2007, shortly before the first mention of the products offered appeared.


2. Neither pricing information nor trial downloads of the products were available at the site (the site is only available now through Google cache).


3. All posts pointing to the company site on MSDN forums were posted by the same user "gauravmangla". Looking at activity of the user one may see that user was registered on May, 2nd 2007 and all his postings are linking to the mentioned company site. No other posts by the same user are found.


4. The only feedback posts on MSDN forums is by some user named "john.matthews01", registered on May, 26th 2007 and whose three posts are concerned solely with praise to the company software. No other posts by the same user are found.


5. No customer feedback from real customers is found using Google (I mean feedback from real-life person non-affilated with the company); only mention of the software in TFS related blogs.

Before I compiled that short list, I was inclined to think that the company in question is new micro-ISV company (of the kind regularily discussed at JoelOnSoftware forums), perhaps with very decent offering that help lost of people in TFS crowd; but now I am of opinion that some fraud scenario might have been at work. My conclusions from that story - before buying something

• Download trial version; if no trial is available then reconsider


• Request client reference/search for users feedback; if none found then reconsider


• If the company is new and the price of the software is significant for you, reconsider


• Use credit card to pay for the software to make sure you get your money back in case of fraud

Update: I stand corrected as the owner of the company in question posted an explanation of the situation; the site is inavailable due to some internal problems ("... a disgruntled employee left our company and he was responsible for our web site. He changed all the passwords and removed all the web site code"); no products was shipped so far due to export limitations so the rumours of products beind paid for and not shipped appear to be just rumours without any solid foundation.
I do hope the company will be able to resolve the internal situation and resume business as usual.

Move caveats (I like to move it move it ... not)

Recent post on MSDN forums reminded me of an important issue in TFS Move functionality.

To give you a short summary - you move file (or more frequently a folder) within your source code repository using TFS Move command. The sky is blue, everything works all right - until at some later point you decide to retrieve the item version before move changes. Then in VS GUI you will receive an error; nothing you do will get you that version using UI. Only possible workaround is to use tf command line get with an old item name/path specified and versionspec before move.

While for most of us it is hardly a show stopper, think about a scenario when you move a whole team project subtree (that's what the author of the original forum post did). If you interested in previous revisions in that setup - that might be pretty cumbersome.

I do not judge the implementation of that; in my opinion you can argue successfully both ways (bug vs logical implementation). But it is certainly the fact to be aware of before you check in the results of your latest move operation.