How to protect trunk from devs

Question

We are using TFS for our code: trunk + branches for coding activities. There are 6 devs in my team.

Problem: sometimes developers don't want to create a new branch (or use an old one) to fix/develop something. They just do it in trunk. OK, in some cases it's acceptable. But most of the time it creates a lot of troubles.

How can I enforce protection of trunk and force devs to create new or reuse old branches?

UPD: I don't want to give read-only access to the devs on trunk (they have to be able to create branches and merge them back by themselves). I want some compromise - can create branches/do merging but can't develop in the trunk.

Answer 1

You can create user group within TFS to give readonly or no acess at all. If you right mouse click over the team project and click group membership, then add those groups to the folder structure in the source control Explorer.

Answer 2

Working on the trunk directly is almost always incorrect. Yes it can be the most efficient way sometimes, but breaking process is breaking process and that will bite you eventually.

I think this problem is best solved with education, but limiting trunk write access to senior devs might help too - if they aren't "infected" too :)

Wortyh bearing in mind though that any good source-repository (read: not VSS) will save you from terminal problems in this area, it's just a matter of effort and watchfulness. You never want to rely on rollbacks, just saying "don't panic".

Answer 3

You can set permissions at the folder level.

Creating a branch is a powerfull permission. You will probably have to have one person who creates the branches and then sets the permissions.

For information on setting permissions see: http://msdn.microsoft.com/en-us/library/ms252587.aspx

Answer 4

I'll second what @annakata said. Additionally, I highly recommend that whomever is responsible for managing SCM in your organization to set up a check-in alert that lets you know when someone checks code into the trunk. That way, you can follow up (with the previously-mentioned cricket bat, if necessary) with the developer responsible.

Some other techniques to consider:

• Only allow senior developers to check in. Developers shelve their changes, and the senior devs review then check-in. They can help be your gatekeeper.

• Use the gated-check-in feature of TFS2010 to help you. Turn on gated check-ins for the trunk.

• Education in a form that developers can understand. Make them know exactly why building off the trunk is a bad thing. SCM process education can go a long way to getting people to comply. If they think it's just an arbitrary rule, they don't feel bad about violating it.

• Add consequences (to whatever degree your organization allows). Things like a beer/pizza fund that they need to contribute to when they screw up, or a funny hat that needs to be worn, or even a loud announcement to the entire development organization when someone checks in to trunk. It gets the point across quickly.

Answer 5

Does TFS has support for running hook scripts like subversion has?

If it has you can run pre-commit and post-commit checks to see if commits follows process guidelines, reject patches with an email explaining why etc.

If thats too much work my best advice is talking to people and use good old reward for adhering to rules and punishment for breaking them.

Answer 6

What kind of "fixes" are they making to the TRUNK? Typically you should never check-in to TRUNK but only merge...

If they have enhancements or bug fixes that can wait and that are not emergencies they should do their development in the DEV branch.

If it is an emergency then branch off of TRUNK and make a HOTFIX branch. This will be a copy of what is in production.

Example of when you would want to use HOTFIX: Let's say you have a change you want to make to production or QA but you don't want the future work done in DEV to go out just yet as it has breaking changes for the QA environment or maybe you just want to be as safe as possible and make sure only the code you know you wanted to change went out with your deployment. If you do not have a HOTFIX branch then click on TRUNK and select "Branch" and name it HOTFIX or something meaningful to you. Then make your changes in HOTFIX, check them in, and deploy from the HOTFIX branch. The HOTFIX will only contain two things then A. What is in TRUNK and B. Your one-off changes. It will not include all of the extra work that you haven't validated or tested from the DEV branch, which is a good thing.