在 Perfarce 克隆中止后，我可以重建 Perforce/Mercurial 连接吗？
我在 Perfarce 扩展中遇到了一个我似乎无法解决的问题。我最初克隆了我的 P4 软件库的一部分：
hg clone --startrev 71555 p4://perforce:1666/greg_nt_main-hg lwnthg
我选择了一个起始版本，它只是当前头部版本后面的一些更改列表 - 尝试没有启动版本的完整克隆是行不通的，但这是一个单独的问题，我可能会写一下分别地。
在克隆过程中，我收到以下错误：
"abort:untracked file in working directory differs from requested revision on 'MAIN/apps/Win32/BenchMark/Jamfile'”
但是，在检查磁盘上出现的内容时，看起来所有文件实际上都已成功克隆。提到的文件与 Peforce 中的文件相同，并且在克隆过程之前 lwnthg 文件夹为空。 “hg status”显示许多尚未提交的文件 - 我猜是因为克隆中止了？所以我承诺了它们，一切看起来都很棒。
我对我的文件进行了一些编辑，并将它们毫无问题地提交到本地存储库。我很喜欢 Mercurial 的可爱之处；）
但是当我将更改推送回 Perforce 时，我收到以下错误：
abort: no p4 changelist revision found
我验证了我有有效的 P4 登录票，P4 已启动，等等，一切正常。
所以我的猜测是，Perfarce 将上次从 P4 同步到的变更列表存储在某处，并且第一次中止发生在该信息写出之前。如果我尝试从 P4 执行拉取操作，我也会收到相同的错误。假设我的理论是正确的，有没有办法在本地 Perfarce 配置中重建这些信息？
注意“Perfarce”不是拼写错误。它是链接到 Perforce 的 Mercurial 扩展的名称。如果你把它改成“Perforce”，这个问题就失去了一些意义。感谢尝试澄清问题的帮助，但始终值得首先检查事实:)
I have hit a problem with the Perfarce extension that I can’t seem to get past. I initially cloned part of my P4 depot by:
hg clone --startrev 71555 p4://perforce:1666/greg_nt_main-hg lwnthg
I chose a start rev that was just a few changelists behind the current head revision – trying a full clone with no startrev didn’t work, but that’s a separate issue I’ll perhaps write about separately.
During the clone I got the following error:
"abort:untracked file in working directory differs from requested revision on 'MAIN/apps/Win32/BenchMark/Jamfile'”
However, on inspection of what had appeared on my disk, it looked like all files had in fact been successfully cloned. The file mentioned was identical to that in Peforce, and the lwnthg folder was empty before the clone process. An ‘hg status’ showed a lot of files that had not yet been committed – I guess because the clone aborted? So I committed them, and all looked to be great.
I made some edits to my files, committed them to the local repo without problems. I enjoyed the loveliness of Mercurial ;)
But when I came to push my changes back to Perforce I get the following error:
abort: no p4 changelist revision found
I verified I had a valid P4 login ticket, P4 was up, etc, and all OK.
So my guess is that Perfarce stores somewhere the changelist that it last synced to from P4, and the first abort happened before this info was written out. If I try a pull operation from P4, I also get the same error. Assuming my theory is correct, is there any way to reconstruct this information in the local Perfarce config?
NOTE 'Perfarce' is NOT a typo. It is the name of the Mercurial extension to link to Perforce. The question loses some of its meaning if you change it to 'Perforce'. Appreciate the help in trying to clear up the question, but always worth checking facts first :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要回答我自己的问题，答案似乎是否定的。
我做了更多的挖掘并与原作者 Frank Kingswood 取得了联系，解决方案是首先确保您的仓库导入没有错误。一旦完成，Perfarce 的工作绝对是一种享受。
最初的导入中止是由于我的使用情况造成的。在遵循其他地方找到的各种说明（包括 Stack Overflow）之后，我尝试使用 hg clone 的目标参数来获取正确的存储库名称。但看起来导入的成功对 Perforce 客户端规范根目录和作为 hg clone 的最后一个参数给出的目标文件夹之间的交互很敏感。
基本上，确保这些文件夹不重叠。
根据 Perforce 中的文件，如果有重叠，它可能可以工作，但您可以将自己设置为一个整体未来麻烦不断。
建议将文件夹分开。我的问题是，我不想将 hg 文件夹的默认文件夹名称作为 Perforce 客户端规范名称 - 如果您不提供目标文件夹，它就会这样做。但是，可能由于错误，如果您确实提供了目标文件夹，那么它必须与客户端规范根匹配。由于这种行为，我认为这些文件夹实际上必须是相同的。
在 Mercurial 中，创建存储库后可以安全地重命名顶级文件夹。因此，如果您不希望名称由 Perforce 客户端规范的名称决定，那么您可以稍后重命名。这就是我采取的方法。
希望这可以帮助其他尝试尝试 Mercurial 水域的人。
更新
Frank 更新了 Perfarce 扩展以更好地捕获这种情况。从 Perfarce 存储库获取最新信息。
To answer my own question, the answer appears to be no.
I've done some more digging and been in contact with the original author - Frank Kingswood - and the solution is to ensure your depot imports without errors in the first place. Once that's done, Perfarce works an absolute treat.
The original abort of the import was down to my usage. After following various instructions found elsewhere - including Stack Overflow - I was trying to use hg clone's destination parameter to get the right repo name. But it looks like the success of the import is sensitive to an interaction between the Perforce client spec root and the destination folder given as this final argument to hg clone.
Basically, make sure these folders do not overlap.
Depending on the files in Perforce, it may work if you have an overlap, but you could be setting yourself up for a whole heap of trouble in the future.
The recommendation is to keep the folders separate. My problem was that I did not want to take the default folder name of the hg folder as the Perforce client spec name - which is what it does if you do not supply a destination folder. But, possibly due to a bug, if you do supply the the destination folder then it has to match the client spec root. Because of this behaviour, I had assumed that the folders actually had to be the same.
In Mercurial it is safe to rename the top level folder after the repo has been created. So if you don't want the name to be dictated by the name of the Perforce client spec, then you can just rename afterwards. That's the approach I took.
Hope this helps others trying to dip their toes in the Mercurial waters.
Update
Frank has updated the Perfarce extension to better trap this case. Get the latest from the Perfarce repository.