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

[Na'Tosha Bard]

2012/5/3 Matt Harbison <matt_harbison at yahoo.com>

> Na'Tosha Bard wrote:
>
>> 2012/5/1 Matt Harbison<matt_harbison at yahoo.**com<matt_harbison at yahoo.com>
>> >
>>
>>  # HG changeset patch
>>> # User Matt Harbison<matt_harbison at yahoo.**com <matt_harbison at yahoo.com>
>>> >
>>> # Date 1335409636 14400
>>> # Branch stable
>>> # Node ID 761b5d75c06a5161549522ce6eb7b4**b57d2d503d
>>> # Parent  038b389d80f5a31520c454d7824596**8de1ecf655
>>> 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.
>

I'm fine with what you describe here.

The lack of camel casing and underscores for separators comes from the code
standard of the Mercurial project as a whole, so there's not much we can do
about that.

Cheers,
Na'Tosha

-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies - Copenhagen

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120503/5a39c4b6/attachment.html>