SVNClient.logMessages 从不返回结果
我正在使用 JavaHL 连接到 1.6 svn 存储库。虽然我设法列出了存储库的内容，但我无法获取项目历史记录（签入时的评论以及日期和作者）。
据我所知， SVNClient.logMessages 是正确的方法，但回调方法从未被执行过。我使用 Revision.HEAD 作为路径修订以及包含 Revision.START 和 Revision.HEAD 的修订范围对象；限制设置为 0（根据文档，这没有限制）。我正在尝试获取修订版本、日期、作者和评论。
如果有人知道使用 JavaHL 的示例代码，我也许可以通过将该代码与我的代码进行比较来找到我的错误。
顺便说一句：我知道 SVNKit，但管理层决定不购买它。因此，我必须使用 JavaHL，其中几乎不存在示例程序（并且文档将仅列出类和接口，而没有非常详细的描述）。所以，请指出 SVNKit 的方向，因为这对我来说是不可能的。
任何指示表示赞赏。
纳尔夫
I'm using JavaHL to connect to a 1.6 svn repos. While I managed to list the contents of the repository, I'm not able to get the item history (the comments made on the check ins as well as the dates and the authors).
As far as I see, SVNClient.logMessages is the right method, but the callback method is never been executed. I used Revision.HEAD for the path revision and a revision range object holding Revision.START and Revision.HEAD; the limit is set to 0 (which is no limit according to the documentation). I'm trying to fetch the revision, the date, the author and the comment.
If someone knows about example code on using JavaHL I'm maybe able to find my fault by comparing that code to mine.
BTW: I know about SVNKit, but the management decided not to buy it. Thus I have to use JavaHL, where next-to-no sample programs exist (and the doc will merely list the classes and interfaces without a very detailed description). So, please point me in that direction of SVNKit as this is impossible for me.
Any pointers appreciated.
Gnarf
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题已经解决。问题是对 SVNClient.logMessages() 的调用，尤其是使用的修订范围。
起始修订版是 Revision.START，根据文档，它用于描述“第一个现有修订版”。
当我使用 Revision.getInstance(1) 时，问题就消失了。由于任何项目至少有一个具有该编号的修订版（初始修订版）是合理的，因此应该保存以使用它。
希望这能让其他人不用再花两天半的时间来弄清楚！
纳尔夫
The issue has been solved. The problem was the call to SVNClient.logMessages(), especially the revision range used.
The start revision had been Revision.START that, according to the documentation, is used to describe the "first existing revision".
The problem disappeared when I used Revision.getInstance(1) instead. As it is reasonable that any item has at least one revision (the initial one) with that number, it should be save to use that.
Hopefully this will save anyone else from spending another two-and-a-half days to figure it out!
Gnarf