Fri, 20 Jul 2012 22:10:52 -0400 largefiles: mark as a first party extension stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 22:10:52 -0400] rev 17233
largefiles: mark as a first party extension
Thu, 19 Jul 2012 23:35:13 -0400 largefiles: ensure addlargefiles() doesn't add a standin as a largefile stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Jul 2012 23:35:13 -0400] rev 17232
largefiles: ensure addlargefiles() doesn't add a standin as a largefile An easy way to force this (and cause a traceback) prior to the fix for 3507 was $ touch large $ hg add --large large $ hg ci -m "add" $ hg remove large $ touch large $ hg addremove --config largefiles.patterns=**large This patch also detected (and corrected) a previous test where a standin got added as a largefile (without a traceback).
Thu, 19 Jul 2012 11:12:05 -0400 largefiles: fix a traceback when addremove follows a remove (issue3507) stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Jul 2012 11:12:05 -0400] rev 17231
largefiles: fix a traceback when addremove follows a remove (issue3507) The problem only occurred if a file was removed with 'hg rm' (as opposed to the OS utilities), and then addremove was run before a commit. Both normal and large files were affected. Ensuring that the file exists prior to an lstat() for size seems like the Right Thing. But oddly enough, the missing file that was causing lstat() to blow up was a standin when a largefile was removed, which seems fishy, because a standin should never be added as a largefile. I was then able to get a standin added as a largefile (whose name is 'large') with hg addremove --config largefiles.patterns=**large which also causes a backtrace. That will be fixed next.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip