是列出“的唯一方法”；“生活”；特定SVN路径的修订“；svn日志-q-v“；加一个过滤器？

对存储库根目录的所有修订执行“svn log-q-v”，然后按所需路径进行过滤真的是最好的（唯一的）方法吗？我们需要找到这些范围，以便为自动化工具提供peg修订，并为我们的变更报告添加支持细节

我已经对查询根目录做了一些优化：

给定路径：

protocol://server/repo/a/b/c/d/foo.txt

我已经编写了一个脚本，在路径上执行重复的svn日志查询：

svn log-q-v…/a/b/c/d/foo.txt
svn日志-q-v…/a/b/c/d
svn日志-q-v…/a/b/c
svn日志-q-v…/a/b
svn日志-q-v…/a
svn日志-q-v

直到我得不到：

svn:未找到文件：

我还没有运行过重要的评测测试，但在我看来，应该相当迅速地处理错误，并且在所有情况下，网络流量的总体潜在减少应该超过重复查询的成本，但无论如何都必须查询存储库根的情况除外。

如果祖先有多个活动范围，上述方法不起作用；除非有人知道得更清楚，否则我唯一的选择就是从存储库根目录进行查询

从结果来看，我基本上想要文件存在的不同范围的列表（稍后我可能会对其进行修改，以跟踪历史，从而使恢复的文件具有多个范围；尽管听起来可能有悖常理，但在某些情况下，具有相同路径的文件最终是不相关的）。目前，我正在解析经过的修订号，跟踪所需路径的最后一个修订，该修订或其祖先之一已被删除（最初为HEAD，如果我看到删除，将被覆盖）。当我看到路径已添加时，我转储一个范围

rev\u added-rev\u lastdelected

上述方法是可行的，但它确实涉及到大量的信息，其中大部分都是虚假的。有没有一种更有效的方法来做到这一点，最好是在服务器端做更多的工作，以尽量减少网络流量（我们的许多工作是通过VPN远程完成的）

---

看来，陆龟VN提供相同信息的唯一方法是执行相同的过程（获取祖先的日志，然后过滤）。

我不这么认为。如果您想以某种方式格式化这些数据，那么您必须获取SVN的输出，并像现在这样处理它

---

svn log filename

的输出应为您提供

filename

的所有相关修订，包括其移动/重命名的历史记录，然后您可以根据需要对其进行格式化。

仅适用于特定的peg修订；如果我在rev 100中添加foo.txt，在rev 110中删除它，然后创建一个全新的、不相关的（就历史而言）foo.txt并将其添加到rev 115中，那么svn log foo.txt默认情况下仅显示-r 115:HEAD。我不会看到-r 100:110中的任何内容来澄清，即使将-r 0:HEAD指定给svn log，也只会显示-r 115:HEAD中的更改。在我刚刚给出的示例中，即使我指定了一个peg修订（foo。txt@100)它仍然没有在rev 110和svn log foo中显示删除。txt@110抱怨该文件在rev 110中不存在。因此，要查看与该路径关联的所有历史记录，唯一的方法是获取该目录的日志。当然，如果目录也有不相交的历史段，则必须向上移动到其目录，可能会一直移动到根目录。因此，我认为我的回答“不”是正确的。将来，您可以通过从旧版本中恢复已删除的文件，而不是在同一路径上创建新文件，来防止历史记录中出现空白。这样，SVN的历史将以您想要的方式跟踪它。只有当这些文件确实不相关时，您才应该创建一个新文件，在这种情况下，您不会希望历史记录跟踪旧文件。实际上，我认为“否”的答案是不正确的。在一些情况下，我确实希望文件是不相关的，例如，旧文件后来被重构为其他几个文件，而且，由于它一开始没有很好的名称，我们创建了一个新文件，其名称与原始文件的名称相同。然而，对于报告，我们仍然需要知道给定路径的可用peg修订。除了遍历整个存储库的整个路径状态历史记录之外，我仍然没有看到一种机制适用于所有可能的情况；没有比这更好的方法了；也许我会考虑扩展svn协议来支持这一点，并使它更接近于一个变更集，而不是使用log、diff和ls的丑陋组合。