Skip to main content

HOWTO: TFS: Can I Prohibit Merging?

Recently a client inquired if it were possible within the Team Foundation Server (TFS) Source Control authorization capabilities to prohibit merging. Having a long week, I brainlessly looked at the authorization options within Source Control Explorer (right-mouse Properties >> Security tab):

image

Nothing there. Then I knocked my forehead and realized one would configure this authorization as part of the branching mechanism. Duh. Merging is a client-side activity. If you can access the TFS server, you can merge. However, committing changes to server source repository requires Check In authorization.

My personal preference is to empower and entrust developers with a fair amount of responsibility. Thus, I like to enable merging into the integration branch for developers. However, this client wanted to restrict developers from merging and reserve this responsibility for accounts belonging to a TFS group (created by default) named "Project Administrators". These are folks playing, for example, the team lead role. Our developers have been added to another TFS group (also created by default) named "Contributors".

Let's assume we're leveraging a simple: Development >> Main >> Production branching mechanism within source control. The Development branch is somewhat wild-wild-west in that you want to impose few impediments to check-ins. Frequency of check-ins usually leads to higher quality (because you're undergoing unit testing and integration more often). So, I have authorization configured to allow Contributors to Read, Check In, etc.:

image

In contrast, the Main branch serves as an integration branch. It should be less wild-wild-west but still flexible. The golden rule here is that no code should be directly checked into Main. It should [almost...a few exceptions] always obtain updates through a merge from the Development branch.

Following my typical paradigm, I would enable Check In for the Contributors within Main. However, for this client, we will revoke that permission for Contributors reserving it for Project Administrators (Note: you'll likely need to uncheck "Inherit security settings"). We'll explicitly deny Check In and Lock while Allow'ing Read:

image

Project Administrators retain full rights:

image

So let's take this one step further into the Production branch. Once the team completes integration testing in the Main branch, we start to call on the Release Manager role. S/he owns the Production branch and should treat it as highly restrictive. In theory, merging from Main into Production should be a formality (ok, in reality, we know this isn't the case but go with me here). With this in mind, let's create a third TFS project group named "Release Managers".

image

We'll keep full rights for the TFS server administrators group but restrict Project Administrators to Read rights and prevent Contributors from even seeing this code (just for fun). (Note: You'll need to explicitly add the Release Managers group we created by clicking the Add button.)

Release Managers:

image

Project Administrators:

image

Contributors:

image

Happy merging!

Comments

Tim said…
Jeff, I know you ended up explaining the situation, but the title definitely got my attention. Why would anybody want to prohibit merging? Prevent overwriting, sure, but merging? Feels wrong.

I do like your release branch set-up. Giving me a few ideas there. (Though I'll implement it in Subversion, since we're using that currently.)
Jeff Hunsaker said…
@tim Agree. This isn't atypical though with clients migrating from a tool lacking true branching support (i.e. SourceSafe). Going from VSS to TFS/SVN/ClearCase is like going from VB6 to C#: it's a complete paradigm shift...and you have to leave all that baggage behind before you can move ahead.
Jeff...

Popular posts from this blog

TFS Reports Out of Date

You may have noticed it takes a while for Team Foundation Server (TFS) reports to reflect changes you've made to work items or builds. Let me guess...about an hour, right? Out of the box, TFS is set to refresh the data warehouse from its transactional store every 60 minutes. How do I change the frequency of the data warehouse refresh? Browse to the TFS Controller Web Service on your TFS application tier server within IE at: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx Select the ChangeSetting option Enter RunIntervalSeconds for the settingId and the desired number of seconds for newValue (300 for 5 minutes...5*60) Select Invoke How do I force a data warehouse refresh? Two methods here: either via the above web service or using SQL Server Management Studio. Via the web service: Browse to the TFS Controller Web Service within IE at: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx Select the Run option Click Invo...

Rollback a Ooops in TFS with TFPT Rollback

Rhut roe, Raggie. You just checked in a merge operation affecting 100's of files in TFS against the wrong branch. Ooops. Well, you can simply roll it back, right? Select the folder in Source Control Explorer and...hey, where's the Rollback? Rollback isn't supported in TFS natively. However, it is supported within the Power Tools leveraging the command-line TFPT.exe utility. It's fairly straightforward to revert back to a previous version--with one caveot. First, download and install the Team Foundation Power Tools 2008 on your workstation. Before proceeding, let's create a workspace dedicated to the rollback. To "true up" the workspace, the rollback operation will peform a Get Latest for every file in your current workspace. This can consume hours (and many GB) with a broad workspace mapping. To work around this, I create a temporary workspace targeted at just the area of source I need to roll back. So let's drill down on our scenario... I'm worki...

VSTS 2008 Data-Driven Web Test

During a client demo this afternoon, I mind-blanked on creating a data-driven web test. Sure enough, I stepped out of the client offices and figured it out. Super. But, I think it's counterintuitive enough to outline in a blog post (...trying to make myself feel better ;-). Somewhat in my defense, I was thinking about data-driven unit tests. These, IMO, are easy to implement. Data-driven web tests are a bit more effort and challenging. Create a web test: Right-mouse on your test project selecting Add >> Web Test. Use the browser recorder to capture your web test scenario. Let's assume you're submitting an age and credit rating to an insurance rate calculator...similar to the screen capture below: Create a table or CSV file (comma-delimited...just use Excel and save as CSV) with relevant headings for your inputs and expected values: From Solution Explorer, double-click on your web test. In the main window, right-mouse on your web test selecting Add Data Sou...