我正在使用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