[PATCH STABLE] largefiles: make archive -S store largefiles instead of standins

[Matt Harbison]

Na'Tosha Bard wrote:
> 2012/5/1 Matt Harbison<matt_harbison at yahoo.com>
>
>> # HG changeset patch
>> # User Matt Harbison<matt_harbison at yahoo.com>
>> # Date 1335409636 14400
>> # Branch stable
>> # Node ID 761b5d75c06a5161549522ce6eb7b4b57d2d503d
>> # Parent  038b389d80f5a31520c454d78245968de1ecf655
>> largefiles: make archive -S store largefiles instead of standins
>>
>> This is essentially a copy of largefile's override of archive() in the
>> archival class, adapted for overriding hgsubrepo's archive().  That
>> means decoding isn't taken into consideration, nor is .hg_archival.txt
>> generated (the same goes for regular subrepos).  Unlike subrepos, but
>> consistent with largefile's handling of the top repo, ui.progress() is
>> *not* called.  This should probably be refactored at some point, but
>> at least this generates the archives properly for now.  Previously,
>> the standins were ignored and the largefiles were archived only for
>> the top level repo.
>>
>> Long term, it would probably be most desirable to figure out how to
>> tweak archival's archive() if necessary such that largefiles doesn't
>> need to override it completely just to special case the translating of
>> standins to the real files.  Largefiles will already return a context
>> with the true largefiles instead of the standins if lfilesrepo's
>> lfstatus is True- perhaps this can be leveraged?
>>
>> diff --git a/hgext/largefiles/overrides.py b/hgext/largefiles/overrides.py
>> --- a/hgext/largefiles/overrides.py
>> +++ b/hgext/largefiles/overrides.py
>> @@ -781,6 +781,47 @@
>>
>>      archiver.done()
>>
>> +def overridearchivefn(orig, repo, ui, archiver, prefix):
>>
>
> This is a nitpick, but if this can't be combined into existing code (and I
> don't see a good place to do so either), wouldn't it at least be better
> named something like 'overridearchivesubrepos', or 'archivesubrepos' or
> similar?  When looking at overrides.py, there's no obvious indication as to
> why on earth we need an 'overridearchive' and 'overridearchivefn'.
>
> Cheers,
> Na'Tosha

Actually, its a good point- one of the problems I had was figuring out 
what a function was overriding without cross referencing uisetup, but 
that seemed to be the style so I figured it was just a matter of me 
getting familiar with the code.  Your comment got me wondering why the 
convention shouldn't just take the form <super class> + <overridden 
function>, e.g. hgsubrepoarchive.  I'm used to camel case, so it doesn't 
take much for an all lowercase identifier to become hard to read. 
Override seems redundant because they are already in a file called 
overrides if a traceback is generated, so dumping that yields a shorter 
name without any downside I can see.  Now I see there are a couple 
largefile method overrides that take this form (e.g. hgupdate), so it 
wouldn't be starting a new style.  Somehow, I missed that before.

So I can resubmit the patch with the name as hgsubrepoarchive if the 
name is acceptable.  Is it worth me making a second patch for default 
that applies this convention to the other wrapped functions for 
consistency?  (Some have override prepended to the name, others don't; 
none name the super class.)  They currently are:

hgsubrepo.status
merge._checkunknownfile
merge.manifestmerge
filemerge.filemerge
cmdutil.copy
hgsubrepo.dirty
commands.revert
archival.archive
cmdutil.bailifchanged
webcommands.decodepath

Some of the names seem awkward is my only hesitation 
(filemergefilemerge?), and I'm not looking to make things less readable 
for the sake of consistency.  It looks like the wrapped commands are 
consistently named override<cmd>, so I don't see anything wrong with that.