When trying to use 'cat' on files added with '--large' I always get a 'no such file in rev XXX' error message. Please see attached shell code as a minimal example to demonstrate the issue: $ ./cat-large-test.sh /home/ipacs/test/cltest large.file: no such file in rev 5c8c7f98150f SMALL works Tested on $ hg --version Mercurial Distributed SCM (version 2.1.1) Is there an alternative way to access a specific revision of a large file directly (without having to check it out to the working directory)? Thanks, Christian
(Add usual suspects.)
Just a quick update: This bug still shows up in hg 2.1.2.
I'm not even sure what appropriate behavior would be in this case. 1) Largefiles are quite often binary, so "catting" them makes no sense, and 2) thinking of `hg cat` with -r flag, users almost certainly don't have every version of a largefile downloaded, so mercurial can't even necessarily know what the contents are of a largefile at some arbitrary revision I'm inclined to think appropriate behavior for largefiles would be something like: $ hg cat mylargefile.foo mylargefile.foo has hash XXXXX at revision YYYYY as opposed to displaying the contents of the largefile.
I think it ought to cat the file, regardless of whether it is large, binary, or readily available locally.
Thanks for the feedback, natosha. We are indeed using 'hg cat -r rev large.file' to allow a user to download a specific revision of a file. So the consumer of the cat is not a terminal (where printing binary data might indeed be useless in many cases), but rather a network socket. I would assume that the general user would expect hg to behave the same when working on files independently of how they were added.
OK, I can see the value of having it just cat the file even if it is binary (or really large). I still think it would be nice if there was a convenient way to get the hash of a largefile at a certain revision, though, it's something that would have been handy (at least for me) on several occasions. Anyway, I'll make plain "hg cat" work correctly on largefiles then; I think I will get something together by the end of the week (it will at least give me a break from being puzzled by addremove issues).
natosha, thanks a lot for your time looking into this. In case it is related, and you are digging through the largefiles source code anyways, could you also consider having a look at this bug report (commit of mixed add (small/large) leaves small files as A): http://mercurial.selenic.com/bts/issue3354 Thanks. Christian
Just to post a follow-up to anyone who is waiting; I only managed to start working on a fix for this today, but now it is reproduced locally and a fix is in-progress.
Proposed patch submitted to development list: http://www.selenic.com/pipermail/mercurial-devel/2012-April/039252.html
Fixed by http://selenic.com/repo/hg/rev/290850e7aa43 Na'Tosha Bard <natosha@unity3d.com> largefiles: fix cat for largefiles (issue3352) (please test the fix)
Patch works for me. Thanks.
Hg 2.2 works for me, also. Thanks. Please let me know if I am supposed to close a ticket, or how else I can help after the testing stage.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:29 EDT --- This bug was previously known as _bug_ 3352 at http://mercurial.selenic.com/bts/issue3352 Imported an attachment (id=1647)