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 🙂
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.