[PATCH 1 of 2 RFC] extdiff: use archiver to take snapshots of committed revisions

[Matt Harbison]

On Wed, 25 Feb 2015 19:06:04 -0500, Mads Kiilerich <mads at kiilerich.com>  
wrote:

> On 02/09/2015 05:01 AM, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at yahoo.com>
>> # Date 1342054131 14400
>> #      Wed Jul 11 20:48:51 2012 -0400
>> # Node ID 6abceaa1a49f82cebd3a4f141f69558e2bb3cec4
>> # Parent  ff5caa8dfd993680d9602ca6ebb14da9de10d5f4
>> extdiff: use archiver to take snapshots of committed revisions
>>
>> [This is the proof of concept that Mathias asked for.  The fix for file
>> archiving from the internal API maybe should be a separate commit.]
>>
>> There should be no visible functional differences, other than the  
>> largefile
>> standins are no longer included in the non working copy snapshots.   
>> That's
>> probably not a big deal, and proper largefile support can still be  
>> added.
>
> I think "proper largefile support" is pretty much the standin handling  
> we already have. It is quite important to not just leave them out; an  
> unreliable diff is bad. Being able to see that a largefile changed is  
> often quite valuable.
>
> Largefiles are in general so large that it could be a problem to copy  
> them out to temp files just for diffing ... and they are often binary  
> and not really diff-able anyway.
>
> I can however also see the use case for tools that can compare images or  
> archives so I guess it would be nice to have both options somehow ...
>
> /Mads

I can see how it would be useful to conditionalize it.  I'm thinking wrap  
the extdiff command and its manufactured deriviatives to add '--large',  
and set lfstatus on the repo if it is specified.  The status call would  
DTRT without changes, but the archival.archive() override in largefiles  
would have to be adjusted to look at it, and its existing two callers  
adjusted appropriately.  Somehow the setting needs to be propagated to  
subrepos too.

--Matt