我正在研究从SourceSafe到Subversion的潜在转变，我们正在努力进行编辑/合并/提交与checkout / update / checkin范例。主要关注的是你如何知道Subversion（以及向谁）检出哪些文件？
在VSS中是否存在与“状态搜索”等效的Subversion？或者由于缺乏“保留结账”而无法实现？
另外，如果我们尝试通过“锁”实现Subversion的“保留检查”，是否有支持“锁定结账”的GUI（TortoiseSVN，VirtualSVN等）？
感谢。
更新：例如，在我们进行构建/发布之前，我们希望绝对确保所有文件都已签入。开发人员忘了。所以我们需要知道哪些文件已签出。这可能与Subversion有关吗？ 是否可以查看已签出（或已锁定）文件的列表？在资源管理器中浏览整个代码库是不可行的，是否有一些报告样式列表或搜索功能？
答案 0 :(得分：8)
如果你正在使用编辑/合并/提交范例（你不需要使用Subversion，btw），那么就没有人会“检出”文件。
在编辑/合并没有文件被锁定的情况下，您将假设每个文件都已签出（解锁）给每个用户。
开发人员下拉整个基线（或者至少是他们想要构建的部分），他们只是在情绪发生时编辑他们想要的任何内容。当他们想要重新检查他们的变化时，那就是“合并”的地方。
乍一看，作为VSS用户，您可能会认为签入文件可以“清除”自您检查后对该文件所做的更改。我不明白这最初是如何起作用的。这里的诀窍是，SVN可以判断其他人在检查了该文件的版本时，因此需要将其合并而不是简单地替换。它比VSS更聪明。 ： - ）
理论是它不应该发生太多，从长远来看，你将花费更少的时间来处理冲突的编辑，而不是花在试图处理别人锁定的文件上。我做过的一次快速的卫生巾计算表明，在我工作的地方可能是正确的，但YMMV。
更新：对于您尝试保护开发人员不要忘记检查更改的过程，这可能不再适用。您可以尝试在每个开发人员的工作目录中查找并查找差异，但我认为我们都同意这是不可行的。
正确的是，锁定模型为开发人员提供了一种方式来声明他们将文件修改为中央存储库的意图，而编辑/合并却没有。为一种方法构建的工具通常只是扁平化而对另一种方法毫无意义。这是其中一种情况。
我建议您作为工具主持人尝试使用SVN进行小型（或玩具）项目，以熟悉不同的工作方法。一旦你理解了这一点，你就应该能够绕过它。
答案 1 :(得分：8)
SVN很乐观：合并冲突很少见且易于解决。 VSS是悲观的：合并冲突很难解决，你可以通过锁定避免它们。所以在svn中，你不需要知道文件被“签出”了。您只需签出一个没有锁定的版本并根据需要进行编辑。冲突在提交之前得到解决，并且通常svn会自动为您解析冲突，除非两个或多个提交正在修改相同的源代码行。
因此，实际上并不需要“状态搜索”。
SVN确实支持锁定的概念，这对那些难以合并的二进制文件很有用。即使在那里锁也不难;它只是向其他开发者发出的信号“请不要在我编辑此文件时提交。” SVN GUI可以选择锁定文件。您还可以使用特殊的svn:needs-lock属性强制执行锁定。
有关锁定的更多信息，请参阅svnbook：http://svnbook.red-bean.com/en/1.2/svn.advanced.locking.html
答案 2 :(得分：2)
TortoiseSVN将告诉您文件是否被锁定，当您在资源管理器或repo浏览器中查看文件时，会在文件上显示锁定图标。
然而，SVN的标准操作方法不像VSS那样锁定/更新/解锁。 SVN中的“Checkout”类似于VSS的“获取最新版本”。
就个人而言，我会避免锁定/更新/解锁工作流程。 SVN中的合并算法比vss好得多。锁定/更新/解锁从根本上反对并发开发。
答案 3 :(得分：2)
马特，
作为转移到SVN的前VSS用户，我可以理解您的挫折感。但是，我相信你已经回答了自己的问题。你已经表明你正在努力从“锁定/编辑/解锁”思维模式转变为“更新/编辑/提交”思维模式，这真的是你沮丧的根源。我知道，因为我自己去过那里。
从根本上说，我认为你试图解决的问题是基于“锁定/编辑/解锁”的思维模式......（正如之前在其他答案中所说的那样）是“限制性安全模型”，即我们我希望保护您不要做有害的事情，这样我们就会限制您的访问权限。 “更新/编辑/提交”思维模式基本上采用的方法是，用户（在这种情况下是开发人员）90％的时间都是值得信赖的，并知道他们在做什么，因此我们将允许您做您想做的事并为您提供当你遇到麻烦时，处理少量的工具。
如果我可能如此大胆地重述您试图解决的问题：
“有时开发人员急于部署新的更改。他们可能忘记将更改提交回存储库，这对于新的更改工作至关重要。这将意味着构建/发布过程将因为这个缺失的更改。构建/发布过程需要知道开发人员是否有任何文件要更改，但其更改尚未保存回存储库。“
这个问题的解决方案将是开发人员提交他们忽略的变更并重新启动构建过程以获得成功的结果。
我可以问一下，这实际发生了多少次？在做了一次之后，开发人员会在一秒钟（或后续时间）做多少次？如果他们是一名持续不断的违法者，那么作为一名团队领导/经理，你有多少次允许它在“鼓励寻求外部职业机会”之前发生？
所以，基本上，我的回答是......训练你的开发人员不要忘记并处理他们忘记的偶然实例。
我假设通过询问是否可以“查看已签出（或已锁定）的文件列表？”您打算对存储库中的所有文件实施独占锁定（否则SVN中没有“锁定”文件的概念）？这严重限制了SVN（或任何其他“更新/更改/提交”模型SCM）相对于VSS（或任何其他“锁定/编辑/解锁”模型SCM）的一大优势。
干杯 理查德
答案 4 :(得分：1)
我真的建议在VSS上转向Subversion（或者，坦率地说，甚至是笔和纸）。更准确地解决您的问题;使用Subversion，您不需要知道谁像VSS一样严重检查文件; Subversion（和合理的源代码控制系统）没有与VSS合并的变化合适。
答案 5 :(得分：1)
我感谢所有的答案/意见。但是，只是为了关闭循环，如果您选择使用锁定/编辑/解锁范例（这可以使用Subversion），您可以使用TortoiseSvn查看所有用户的所有当前锁定。
答案 6 :(得分：0)
AnkhSVN支持从Visual Studio锁定编辑，但即使我处理该功能，我也建议只在没有其他选项（例如特定生成的代码和二进制文件）时才使用它。对于开发人员正在处理不同任务的团队中的普通源文件，几乎不需要执行独占锁定。
免费的SourceGear DiffMerge这样的好的3向合并工具可以很容易地解决偶然的冲突（可能每隔几个月对整个团队进行一次;而不是更多）。
答案 7 :(得分：0)
http://svnbook.red-bean.com/en/1.5/svn.ref.svnadmin.c.lslocks.html
$ svnadmin lslocks /var/svn/repos
Path: /tree.jpg
UUID Token: opaquelocktoken:ab00ddf0-6afb-0310-9cd0-dda813329753
Owner: harry
Created: 2005-07-08 17:27:36 -0500 (Fri, 08 Jul 2005)
Expires:
Comment (1 line):
Rework the uppermost branches on the bald cypress in the foreground.