我们决定将 .NET 项目的源代码控制从 SourceSafe 切换到 Mercurial。
现在的问题是,是否有可能知道解决方案中的哪个文件被“提取”(签出),如果是,由谁?
我们决定将 .NET 项目的源代码控制从 SourceSafe 切换到 Mercurial。
现在的问题是,是否有可能知道解决方案中的哪个文件被“提取”(签出),如果是,由谁?
“签出”用于指示其他人不应修改该文件。这通常被称为锁定,但它不再是 VCS 系统如何工作的基础;现代系统可以逐行合并更改,并在更改冲突的极少数情况下提供交互式帮助。(当我第一次听说它时我持怀疑态度,但它真的很好用)。
在 Mercurial 中,每个用户都有自己的存储库克隆。我假设您的组织还建立了一个每个人都与之同步的“中央”存储库。坐在您的工作站前,使用hg incoming
它来查明其他人是否已将更改推送到您尚未拥有的中央服务器。但是您只会看到已“推送”到中央存储库的更改。在 mercurial 中,用户可以多次签入对其本地克隆的更改,并且在它们被“推送”到中央存储库之前,它们将保持私有状态。所以你不能问谁打算修改某个文件,只能问谁已经提交了修改。
(警告:这遗漏了很多细节。研究mercurial 的书以了解系统的工作原理,以及如何充分利用它)。
也就是说,mercurial 确实具有文件锁定功能。它由LockExtension 提供。您可以将某些类型的文件配置为需要锁定;其他用户可以查看文件是否被锁定,并且被阻止向其推送更改(除非他们“窃取”您的锁,因为您可能会锁定文件并去度假,所以他们可以这样做)。
最后:在评论中,您提到了某种文件,不应由一个以上的人处理。在反复无常的术语中,这是一个永远不应合并更改的文件。图像文件和其他所谓的“二进制”格式最常出现这种情况。处理它们的灵活方法不是锁定,而是防止工具不连贯地“合并”两个二进制修改。您可以通过将[merge-patterns]
配置设置为将您的特殊文件视为“二进制”来做到这一点;看到这个问题得到一般的想法。
简而言之:如果你真的想要锁,你可以拥有它们,但是有更好的方法来管理你的团队的协作。学会利用它们,你可能根本不需要锁。
在 mercurial 中,文件不会像这样“签出”,而是在 mercurial 的暂存区域(本地)中跟踪文件。如果你hg status
从终端运行。它将向您显示它正在跟踪的当前修改的文件以及它不知道的任何文件。
因此,当您提交时,它将提交已修改的跟踪文件。要将未跟踪的文件添加到暂存区域,您可以添加所有未跟踪的文件hg add .
您无需担心签出文件,mercurial 知道您所做的更改。
当您使用 Visual Studio 时,您可以安装一个插件(类似这样的东西),它将 Mercurial 与 IDE 集成并在解决方案资源管理器中显示不同的图标来修改文件
不,Mercurial 没有完全的“锁定/解锁”模型,只有分支/合并。合并完全不是问题,如果在处理过程中必须合并二进制工件,它可能只有一些缺点(并且在 SCM 中存储这种类型的对象无论如何都是反模式)。
对于 DVCS 而言,锁定的情况比 CVCS 更糟糕 - 因为每个工作区都有自己的存储库副本,独立于其他工作区,因此无法检查和检测所有克隆中某些文件的状态。
如果存储库中的可变二进制对象对于您的工作流程来说是必须的并且您无法避免它,您可以考虑两个(不同的)事情:
不,Mercurial 是分散的源代码控制。没有办法可靠地知道其他人可能检查了什么。
也许你可以用钩子构建一些东西,但我建议不要这样做。您可能最终会在维护这样的解决方案时遇到麻烦,而且它会很脆弱,因为可以在本地禁用挂钩。
Mercurial LockExtension 在 概念上提供了您正在寻找的东西,但我不确定它是否已准备好迎接黄金时段。我无法让它与中央存储库一起运行。