TFS

Blog moved to : http://tomafischer.com

ftom — Wed, 11 Aug 2010 20:51:36 GMT

I finally decided to move to my own site:

http://tomafischer.com/

I moved most of the blog entries to the new site.

Please update your RSS feeds.

Thanks

Tom

TFS Error: The item does not exist at the specified version

ftom — Tue, 30 Sep 2008 22:15:00 GMT

After moving a branch from one TFS server to another I got the error:

"The item \$TFSProject\mylocation\myfile.cs does not exist at the specified version".

First I thought the Check in was buggy and went to another machine. And like a miracle it worked there.

Then I googled and found out that this usually relates a messed up workspace.

Especially the following link was very interesting:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2367863&SiteID=1

But this was not my problem.
I had two Visual Studios (2008) open.
Inside one instance I used the Team Explorer to disconnect from one TFS server and connected to another TFS server without closing the second instance or restarting VS.
I guess the TFS integration in VS got confused and was choking.

So I restarted VS and everything went back to normal.

Sometimes a simple restart does the trick. But at least I learned about how to delete your workspace :-)

Tom

When to create a new TFS project or reuse an existing one

ftom — Mon, 29 Sep 2008 21:47:25 GMT

I am sorry this is not a C# blog today. I am still in TFS land :-)

Recently I was talking to different people about when to create a new TFS project or reuse an existing one.

Here is what I got out of the conversations:
- Too many projects slow down the server and are hard to maintain. (Depending on the project type, TFS 2008 has an upper limit of around 200 - 500 projects)

- Security on too many projects can be very hard to maintain (especially keeping track of current permissions, removing expired permissions, etc.)

- Using the built-in TFS Groups in TFS is usually enough. Add NT accounts/groups manually to certain permissions if you have to.

- If the intent of adding a project to TFS is simply to have Source Control, try to stick it into a group specific (generic) TFS project. Move it later if necessary.

- If you don't know exactly how much project management will be included or how big the project will be, stick it in a current TFS project and move it later.

- Moving Source control Items from one TFS project to another works great and is very easy. The history is still searchable.

- Moving Work items is super tricky and should be minimized. See http://blogs.msdn.com/granth/archive/2008/06/26/how-to-move-work-items-between-team-projects.aspx

- Separating Source Control and Project Management causes more work, because you have to modify the default queries.

- IF you need exclusive permissions for the same user => new TFS project

- IF you need different Template => new TFS projects

See http://msdn.microsoft.com/en-us/library/ms242894.aspx for a more thorough analysis.

I hope this might help you.
Tom

P.S.: Special thanks to Scott, Robert, and Jeevan for all your input and being a great sounding board!

What are good Check in Policies for TFS?

ftom — Wed, 20 Aug 2008 19:48:26 GMT

Hi y'all

Today I was asking myself an interesting question. So please everyone who read this please give comments!!!!

Me as a developer, I do not like rules for Source Control.

But as soon as your local machine crashes or you get a solution out of TFS which does not compile or you become a Project Manager or …. You really feel like making a change to my own habits. Pain is sometimes the best motivator.

But what are the best rules for TFS (or SourceControl in general) without going overboard?

Here are some basic rules I came up with:

- Check in/ Shelfing every night is required. Every morning at around 4 am run a script to see what was not checked in and send an "informal" email of all "offenders" to the DEV Team.

- Every check in starts a continuous integration process and checks if the solution still builds. If not: Notification Email

- NO LOCAL CODE on any machine which is not checked in (even little helper tools for troubleshooting) . This is a tough one to enforce but worth making a value out of it. Maybe have independent project where everyone can have their own snippets or little test tools.

- Minimize Branching. But if you need it USE IT! Use Labeling as an alternative

Am I missing something? But I think this would solve most of the Source Control problems IT-Shops are facing

What are your thoughts?

Tom