TFS 结帐锁定最佳实践 [英] TFS checkout lock best practices

问题描述

我很难说服组织中的其他人停止在结帐时不加选择地锁定文件.我可以找到解释为什么应该谨慎使用结帐锁的官方"文档的任何想法?微软建议:

I'm having difficulty convincing others in my organization to stop indiscriminately locking files on checkout. Any ideas where I can find an "official" document explaining why a checkout lock should be used sparingly? Microsoft recommends:

作为最佳实践，请谨慎使用锁定类型选项并通知您的队友您锁定项目的原因以及您计划的时间解除锁定.

As a best practice, use the Lock type option with discretion and notify your teammates why you are locking an item, and when you plan to remove the lock.

但不涉及任何细节.

我能指出的任何东西都会非常有帮助.

Anything that I could point to would be very helpful.

推荐答案

虽然我没有 Microsoft 的官方资源，但我是应用程序生命周期管理领域的 MVP，所以希望这足以使本文引人注目.:)

Although I don't have an official Microsoft source, I'm an MVP in Application Lifecycle Management, so hopefully that's enough to make this compelling. :)

在结帐时锁定文本文件(即代码)可能会严重阻碍生产力.当我在同事不在的时候工作时，我自己也看到过，他们对文件有独占锁.突然之间，这是拇指摆弄的时间.当您尝试排查或修复时间紧迫的问题时，情况会更糟.

Locking text files (i.e. code) on check-out can be a massive impediment to productivity. I've seen it myself when I was working at a time a co-worker wasn't, and they had an exclusive lock on a file. All of a sudden, it's thumb-twiddling time. It's even worse when you're trying to troubleshoot or fix a time-critical issue.

人们想要锁定文件以进行独占编辑的最常见原因是因为他们不想稍后执行混乱的合并.

The most common reason why people want to lock a file for exclusive editing is because they don't want to have to perform a messy merge later on.

这通常是一件或多件事情的征兆:

That is usually symptomatic of one or more things:

• 被独占锁定的文件太大(一个文件中有很多类，一个做太多事情的神类"等).这个问题的解决方案是根据单一职责原则将代码重构为更小、更孤立的类.或者，如果您绝对必须，并且您在 .NET 世界中工作，请滥用 partial 关键字将同一类拆分到多个文件中，尽管我想记录下来并声明每次我在代码库中看到这个，都会让我流下无限悲伤的泪水.
• 被独占锁定的文件正在进行重大的长期重构.这里的解决方案是隔离分支内的主要变化，频繁地将变化从主干反向集成到分支.
• 进行更改的人只是不喜欢合并.我帮不了你.如果您保留代码而没有提交代码的时间足够长，以至于合并会很痛苦，那么您提交代码的频率就不够高.如果您因为代码尚未完成而没有提交代码，但更改正在进行中并且您不想干扰其他人的工作，那么您没有正确使用分支.

• The files being exclusively locked are too big (one file with lots of classes in it, a "god class" that does too many things, etc). The resolution for this problem is to refactor code into smaller, more isolated classes according to the Single Responsibility Principle. Or, if you absolutely must, and you're working in the .NET world, abuse the partial keyword to split the same class up across multiple files, although I want to go on the record and state that every time I see this in a codebase it makes me cry a single tear of infinite sorrow.
• The files being exclusively locked are in the midst of major, long-term refactoring. The solution here is to isolate major changes within branches, with frequent reverse-integrations of changes from the trunk back to the branch.
• The person doing the change just doesn't like merges. I can't help you with that one. If you're holding onto code without committing it for a long enough time that a merge is going to be painful, you're not committing your code often enough. If you're not committing your code because it's not done yet, but the change is ongoing and you don't want to interfere with others' work, then you're not using branches properly.

有时对代码文件的排他锁是好的和有用的吗?可能，但我想不出它解决了使用其他更合适的源代码控制功能无法解决的问题.

Can there be times when exclusive locks against code files are good and useful? Probably, but I can't think of a problem that it addresses that can't be addressed by using other, more appropriate source control features.

如果可以，请使用本地工作区，因为它们不强制执行排他锁.

Use Local workspaces if you can, since they don't enforce exclusive locks.

这篇关于TFS 结帐锁定最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！