Last week there was some analysis of how various tools did during particular merge operations (especially cherry-pick). I got the word back from one of the people in that effort that my personal favorite 3-way merge tool ( KDiff3 ) did quite horribly...

One of the V1 decisions we made was to not allow partially trusted callers in our policy framework. Since we're expecting the vast majority (if not all) checkin policies to be installed on the client machine, this isn't too big of a deal. However,...

Last week, I made a sample policy for an internal team and got an email today with (basically) "Great! Now how to we add it?". While the official page on customizing checkin policies details most of the steps, it leaves out one step that for V1 we're...

Our RC bits were built Friday morning , and starting tomorrow, you can have at them! This will be the first Go-Live build available with a lot of the VS Add-in extensibility we've done post-Beta3 (see Ed's post on the Version Control additions , for instance...

This has come up in the forums a good bit, and I'm sure it's covered in other blog posts as well, but given the times it comes up, having another blog post for potential search engine matching seems like a decent idea (and, well, Adam told me to). ...

Nothing TF-related here - while writing up some simple example apps, I find myself not liking that while there's the "cw" snippet for Console.WriteLine, there's nothing for Console.Error.WriteLine, so I made a couple of very simple snippets - cew for...

A request that's come up a couple of times is to have a checkin policy help guide developers about certain file extensions that they shouldn't check in to version control. While making a policy with "forbidden extensions" is certainly possible, it's basically...