What are good Check in Policies for TFS?

Geeks With Blogs

Tom Fischer

<< Silverlight (SL2B2) Bug in Blend (Preview 2.5) | Home | Why it is time to retire the old cast operator in C#: MyType t= (MyType)o >>

What are good Check in Policies for TFS?

Comments (5) | Share

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

Posted on Wednesday, August 20, 2008 2:48 PM TFS | Back to top

Comments on this post: What are good Check in Policies for TFS?

# re: What are good Check in Policies for TFS?

How about mandatory useful comments on each check in as well? The hard part is defining "useful"!

I completely agree on he CI build processes... those are a huge help.

Left by Scott Davison on Aug 20, 2008 4:48 PM

# re: What are good Check in Policies for TFS?

Very good point. I hate it when you look at he history and there a no comment. Even a on word comment makes a difference.

Left by Tom Fischer on Aug 20, 2008 6:25 PM

# re: What are good Check in Policies for TFS?

I personally wouldn't force people to check in their code every night. As long as the build doesn't break, that's all I would worry about.

I also like the mandatory comments rule, and kicking off a build on every checkin is a great idea.

I'm not that knowledgeable about TFS, but I think there's also something about running a coding standards checker, isn't there? It could enforce all of the coding standards that can be done when you do Edit -> Advanced -> Format Document in Visual Studio.

Why are people doing their own branching? Shouldn't only the build manager be doing that kind of thing, and only using it for a separate version of the code that needs to be maintained? Labeling and branching are quite different.

Is there a way to enforce that a checkin is related to a work item? This can help with project management as well as backing out all related changes for a work item.

Left by Mike Ellis on Aug 20, 2008 9:00 PM

# re: What are good Check in Policies for TFS?

I agree with Branching argument. What I have seen a lot is that instead of just lableing they branched the projects. That's why I also agree only the built manager or Project lead should have the right to branch projects.

And yes there is a way of linking a workitem to a checkin. We used this in my old company. But unfortunatelly I've never seen any useful reporting on it. But this is also somehting which might be worth spending time on.

Checking in every night.. it is a difficult topic for me. We had a coworker who died during the weekend and then we had to go back into his machine and try to find out where the current code is. This was I very painful and emotional experience. I guess after this I rather have it checked in or just shelfed in the evening. But I can see that being more flexible is okay for certain groups.
Tom
Tom

Left by Tom Fischer on Aug 21, 2008 8:21 AM

# re: What are good Check in Policies for TFS?

I think if source is checked out more than 24 hours then the dev should check-in or undo check-out. The reason being if I check something out in the evening before I go home, I will probably check it in the next morning or afternoon (more than likely before 24 hour timeframe).

**disclaimer: this assumes the modified source is on a machine that can be accessed by peers and/or manager in case that person wins the lottery.

Branch only when you must, but minimize merging from the trunk into the branch(es) if the trunk churns a lot. TFS cries when renaming/removing files from trunk which exist in the branch (IMHO). Re-branching helps to define exactly what was captured instead of reporting on the check-ins to find what was 'active' for the point in time you are interested.

Left by rustycoslett on Aug 27, 2008 9:56 AM

Your comment:

Title:

Name:

Email: (never displayed) (will show your gravatar)

Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code

Verification:

ASP.Net SQL Server Apple Google SharePoint Windows Visual Studio Team Foundation Server Agile Office Design Patterns Web Azure