When converting a hg repos that uses the largefiles extension, The following happens: - the conversion starts and runs for a while - it crashes because of wrong content of the (dummy) 00changelog.i Then a partially repos is left in some intermediate state. Resolution (hard): - write largefiles support Resolution (easy): - check if largefiles is active and bail out with an error message. cheers - Chris
AFAICS it fails decently ... but with room for improvement: --- a/tests/test-lfconvert.t +++ b/tests/test-lfconvert.t @@ -4,6 +4,7 @@ > share = > graphlog = > mq = + > convert= > [largefiles] > minsize = 0.5 > patterns = **.other @@ -270,3 +271,16 @@ pass $ cd .. + + $ hg convert largefiles-repo + assuming destination largefiles-repo-hg + initializing destination largefiles-repo-hg repository + scanning source... + sorting... + converting... + 6 add large, normal1 + abort: No such file or directory: $TESTTMP/largefiles-repo-hg/.hglf/large + [255] + $ hg -R largefiles-repo-hg glog --template "{rev}:{node|short} {desc|firstline}\n" + o 0:d4892ec57ce2 add large, normal1 If you see a real crash then please show the actual output ... and preferably also a full test case.
I will try to find a traceback. My error messy was really a complaint about 00changelog.i which exists in the place where normal repos expect it, but with a syntax changed for largefiles (just a "wrong" message note), while the true, new 00changelog.i is in a different location. The dummy file shows minimax:didoca tismer$ hexdump -C .hg/00changelog.i 00000000 00 00 00 02 20 64 75 6d 6d 79 20 63 68 61 6e 67 |.... dummy chang| 00000010 65 6c 6f 67 20 74 6f 20 70 72 65 76 65 6e 74 20 |elog to prevent | 00000020 75 73 69 6e 67 20 74 68 65 20 6f 6c 64 20 72 65 |using the old re| 00000030 70 6f 20 6c 61 79 6f 75 74 |po layout| 00000039 This is a syntax that hg convert does not expect. And it is not aware of this possibility. The real one is in .hg/store/00changelog.i I think, hg convert should at least probe this and bail out with an error message that it cannot handle this.
If Mercurial ever tries to read that file, you've either a) got an ancient version of Mercurial b) have a missing or damaged 'requires' file
Not accepted: - Mercurial was the latest official version at the time of reporting - I was never asked by anything to have a 'requires' file and in any case, this argumentation makes little sense. Even if I made errors (which I seem didn't), an application should never crash with a random error message, but check if it will be able to run instead of running a bit, then crashing and leaving the new repos in some unusable state. In any case, to recover gracefully is a must (talking as a python core developer). I don't see the point in your argument. I was hit by this bug, and two colleagues on a different platform as well. What are you trying to defend, instead of being happy that somebody cares? Your arguments "this is either or" seems to be incorrect. No offense, just a reaction to absolute statements. cheers - Chris
We need more information. Do you have a .hg/requires file or not? Attach a traceback.
I still have the unconverted repos on my machine. Yes, there is a requires file with this content: largefiles revlogv1 fncache store dotencode There is no traceback, just an abort message. First and last couple of lines of the log: macgyver:didoca.off tismer$ hg convert --filemap private/private.filemap.txt . ../tmp.private initializing destination ../tmp.private repository scanning source... sorting... converting... 350 blah 349 initial checkin for reading IBF- and CDB-/-RDB-files, some refactoring needed 348 Veit's Skizze 347 merge (... lines skipped) 17 changed language of the documentation to german 16 converted file from latin1 to utf-8 15 Switched template editor to configuration 14 Added links 13 added description of files which has to be moved to the private repository 12 moved files to private directory transaction abort! rollback completed abort: integrity check failed on 00changelog.i:67! macgyver:didoca.off tismer$ Unfortunately I cannot send a copy of the repos, because it contains private data (actually the reason why we splitted). cheers - chris
Ok, then .hg/00changelog.i is completely unrelated... and is not being read. It's a placeholder to cause old versions of Mercurial to not attempt to read repos. The interesting file is probably .hg/store/00changelog.i ... but it's probably empty again by the time the rollback is complete.
I just need to rescue my corrupted repository then I encounter this this problem, actually it's not crash, here is my example to reproduce this issue 51G demo # mkdir orig; pushd orig; hg init; truncate -s 1m a; hg add a; hg commit -m 'orig'; popd; /tmp/demo/orig /tmp/demo /tmp/demo 51G demo # hg lfconvert -s 1 orig lfrepo; initializing destination lfrepo 51G demo # hg convert lfrepo normrepo; initializing destination normrepo repository scanning source... sorting... converting... 0 orig abort: No such file or directory: /tmp/demo/normrepo/.hglf/a 51G demo #
Closing, gone cold. Last message unrelated to this bug.
Reopening. The last comment may be about 3519, which is fixed, but this is definitely a problem. The changelog.i file seems irrelevant. Patches submitted here: http://www.selenic.com/pipermail/mercurial-devel/2012-October/045620.html
Fixed by http://selenic.com/repo/hg/rev/92bbb21d4b13 Matt Harbison <matt_harbison@yahoo.com> largefiles: respect the rev when reading standins in copytostore() (issue3630) When the rev isn't specified, the standin for the working copy gets read. But convert doesn't update the working copy for each cset it processes, so there is no standin and the 'hg convert' would abort complaining about the standin being missing. Note that if the largefile is not in the user cache, 'hg convert' complains about the largefile itself missing from the destination repo. (please test the fix)