1

I just wrote a small custom check-in policy to keep myself from checking in temporary settings (such as, for instance, having web.config point to my local database server, instead of the real one).

I don't know that anyone else on my team wants this policy, so can I create the policy just for myself?

(According to this SO answer you can't, but that was TFS2010, so I'm hoping this has changed.)

Community
  • 1
  • 1
Joshua Frank
  • 13,120
  • 11
  • 46
  • 95

2 Answers2

0

You could consider using Git for TFS. Its available in TFS 2013 / TFS Online.

Git expects you to work locally a lot and have your own settings while TFSVC wants you to do more stuff server side.

http://blogs.msdn.com/b/visualstudiouk/archive/2013/08/05/well-i-like-team-foundation-server-and-i-like-git-but-which-is-better.aspx

http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/30/getting-started-with-git-in-visual-studio-and-team-foundation-service.aspx

That said, for things like configuration settings, you should probably have those set by a build/deployment server, or use the publish settings and always have your development config set to work on development databases (local or shared, but not production)

John
  • 6,503
  • 3
  • 37
  • 58
  • I need to use TFS because my whole team does, and I want to stay very close to the usual workflow, so I'm not sure this would be good for me. I'll check out how it works though. Thanks. – Joshua Frank Nov 03 '14 at 18:46
  • I'm not suggesting you use git and the rest of the team uses TFSVC, I'm saying you might want to talk with them about changing to TFS with a git repository instead of TFSVC. TFS natively supports git and it works really well. That said, for things like configuration settings, you should probably have those set by a build/deployment server, or use the publish settings – John Nov 03 '14 at 18:54
  • 1
    That's using a sledgehammer to crack a nut! – Jason Williams Nov 03 '14 at 20:00
  • @JasonWilliams its not much to switch over to git in TFS, and it will enable them to do more branching than the headaches that are server side branches. Now TFSVC works much better than it used to, but there are some nice quality of life things that git can provide as shown in the two MSDN blogs I linked. – John Nov 03 '14 at 20:02
0

We achieve this by changing the check in permissions on the file in Source Control. You can set it so that it only applies to certain individuals or groups, and by denying "check in", everyone can still check out and locally edit the file, but they get an error if they accidentally try to check the file back in.

To check in a permanent change to the file you just grant the permission back to the relevant person for a few minutes, then set it back to deny once they have checked in.

See the TF.exe permission command.

Jason Williams
  • 56,972
  • 11
  • 108
  • 137
  • But I don't want the restriction to be that total. I want to be able to check in any file, but just use the policy to detect if I've left a problem in one file. Having to globally block myself from checking in the file even when it's fine, or correct the error but then have to do a manual step to grant myself permission, commit, and then ungrant it, still seems like a pretty big hammer for this nut. – Joshua Frank Nov 03 '14 at 20:02
  • It only takes a 3-line batch script to unlock the file, check it in and lock it again - so no, it's not a "big" solution at all. Certainly much less complex (and more individually targetable to different users) than a check-in policy. But the most important thing is to use whatever tool/technology you are happiest with, as you're the one who has to use/maintain it. You may find a policy works better for you because you can make it do several useful things in one hit. – Jason Williams Nov 03 '14 at 22:44
  • I'm thinking about it, but it's not just the lines of code, it's the granularity. My policy has a fair amount of smarts about what it enforces. It sounds like this solution locks the file so I can't accidentally check it in, but doesn't really guide me about what might be wrong; I have to manually inspect it to make sure it's right. My policy checks for exact problems and reports on them in detail, so I know what the violation is. Could that be done with a batch file? – Joshua Frank Nov 04 '14 at 01:28
  • No, I misunderstood your question. My answer is a way to stop yourself accidentally checking in debugging settings over your release version of the file. If you want to test a lot of context to make the decision about whether or not to allow a check-in, then a C.I. Policy sounds like a much better approach. You just have to make sure you deploy your policy in a way that means it works correctly for everyone on your team. Or change your build to copy the release config file from somewhere else so it's easy to edit, but you can't accidentally release the debug config file to your customers. – Jason Williams Nov 04 '14 at 19:52