[PATCH 2 of 4 V2] largefiles: pass a matcher instead of a raw file list to removelargefiles()

Matt Harbison mharbison72 at gmail.com
Sun Jan 4 14:57:32 CST 2015


On Fri, 02 Jan 2015 18:10:58 -0500, Matt Harbison <mharbison72 at gmail.com>  
wrote:

> On Fri, 02 Jan 2015 17:21:48 -0500, Matt Mackall <mpm at selenic.com> wrote:
>
>> On Tue, 2014-12-30 at 19:55 -0500, Matt Harbison wrote:
>>> # HG changeset patch
>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>> # Date 1417222252 18000
>>> #      Fri Nov 28 19:50:52 2014 -0500
>>> # Node ID fd07d758b7d15cc77d169b687bc11f76d9daf9c9
>>> # Parent  e8d4bf9e91698f57bd8485a093b0c9ae6a7f0271
>>> largefiles: pass a matcher instead of a raw file list to  
>>> removelargefiles()
>>
>> Breaks tests:
>>
>> --- /home/mpm/hg-test-/tests/test-largefiles-misc.t
>> +++ /home/mpm/hg-test-/tests/test-largefiles-misc.t.err
>> @@ -313,23 +313,27 @@
>>    0 largefiles updated, 1 removed
>>    0 files updated, 0 files merged, 2 files removed, 0 files unresolved
>>    $ hg status -S
>> +  R large.dat
>>    $ hg update tip
>>    getting changed largefiles
>>    1 largefiles updated, 0 removed
>>    2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>>    $ hg status -S
>> +  R large.dat
>>  # modify a large file
>>    $ echo "modified" > subrepo/large.txt
>>    $ hg st -S
>>    M subrepo/large.txt
>> +  R large.dat
>>  # update -C should revert the change.
>>    $ hg update -C
>>    getting changed largefiles
>>    1 largefiles updated, 0 removed
>>    getting changed largefiles
>> -  0 largefiles updated, 0 removed
>> -  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> +  abort: No such file or directory: '$TESTTMP/statusmatch/large.dat'
>> +  [255]
>>    $ hg status -S
>> +  R large.dat
>>
>
> It looks like 1265a3a71d75 is the problem (which went out yesterday).   
> If I back it out, no test breakage.  It looks like the test changes mean  
> there is a case where a removed largefile will be reported as 'R', even  
> after the commit, even though it is gone from the filesystem.  (It's  
> also strange that update -C fails just because the largefile is missing,  
> but maybe it is because status is confused).
>
> Mads, can you take a look at this?  Even if you just backout your change  
> so I can resubmit this, we will apparently get some further test  
> coverage on default.

I submitted a patch for stable to fix this.  I didn't trace all the way  
through to see why the commit referenced above caused the problem, but it  
was obvious there's been a long unhandled case with largefile removal once  
I understood the test changes.

--Matt


More information about the Mercurial-devel mailing list