我正在使用Mercurial GUI客户端，它通过命令行（首选的高级API，根据我的理解）与hg.exe进行交互。Mercurial命令行“API”参考？
但是，我无法确定每个命令的可能输出。我可以通过模拟情况看到几个输出，但我想知道是否有每个命令的可能输出的完整参考。
例如，对于命令hg fetch，一些可能的输出是：
pulling from https://[email protected]/Repo
searching for changes
no changes found
如果没有变化，或：
abort: outstanding uncommitted changes
或几个其他消息之一，视情况而定。
我想构建我的程序来处理尽可能多的这些情况，但我很难事先知道它们是什么。
是否有文档参考的命令行？我一直没有找到与谷歌。
翻阅翻译字符串文件。然后你就会知道你处理了每条信息，并能够看到它的哪些部分有所不同。
另外，fetch只是拉/更新/合并的一个便捷包装。如果您以编程方式调用mercurial，则可能希望在运行时将这三个截然不同的概念分开，以便知道哪个部分失败。在你上面的例子中，'更新'失败了，所以'拉'将会成功，'更新失败将允许你为用户提供更好的信息。
（取是一种可憎的，这就是为什么它的默认禁用的一部分）
难道这就是你要找的人：https://www.mercurial-scm.org/wiki/MercurialBook？
不是我在找的东西，虽然这是使用Mercurial的有用资源。我一直在开发一个程序，通过发送命令然后解析输出来与'hg.exe'交互，并且需要一些命令的每个可能结果的非常特定的文档，这是编程API文档的方式。用户文档对可能发生的情况不是很具体，特别是几乎没有关于错误的信息。 – 2012-02-25 00:58:32
Mercurial 1.9带来了一个稳定的command server（从某种意义上API不会改变那么多）和低开销（不需要为每个命令运行hg进程）。通信是通过管道完成的。
检查字符串文件是一个好主意，虽然这并不能提供一种简单的方法来确定每个命令的可能响应。该文件中大约有200个字符串;我并不认为我可以正确识别每一个的上下文（或上下文）。关于你的'fetch'tirade：我意识到它可能并不是纯DVCS的最好例子，但我在实践中发现，我经常想要将所有这3个动作组合在一起，这使得它很方便。但是，嘿，这是配置文件的用途，对不对？ – 2010-09-07 19:32:07
是的，当人类运行时，'fetch'更好，但如果你将任何东西自动化，这是一个非常可疑的选择。 :)不幸的是，mercurial的退出代码（在wiki中记录）也不是非常有用。一般来说，如果事情变得更糟糕，某些事情就不会奏效，如果所有事情都做好了，你就会取得成功。 – 2010-09-07 20:01:52