[PATCH RFC] extdiff: add support for subrepo diff

Matt Harbison mharbison72 at gmail.com
Sun Feb 8 12:50:30 CST 2015


On Sun, 08 Feb 2015 06:24:41 -0500, Mathias De Maré  
<mathias.demare at gmail.com> wrote:

> On Sat, Feb 7, 2015 at 5:58 PM, Matt Harbison <mharbison72 at gmail.com>  
> wrote:
>
>> On Sat, 07 Feb 2015 05:03:09 -0500, Yuya Nishihara <yuya at tcha.org>  
>> wrote:
>>
>>  On Sat, 07 Feb 2015 09:56:09 +0100, Mathias De Maré wrote:
>>>
>>>> # HG changeset patch
>>>> # User Mathias De Maré <mathias.demare at gmail.com>
>>>> # Date 1423299130 -3600
>>>> #      Sam Feb 07 09:52:10 2015 +0100
>>>> # Node ID dd4c16684d072b2eb35d0ef5f6e567eb9ea5b430
>>>> # Parent  ff5caa8dfd993680d9602ca6ebb14da9de10d5f4
>>>> extdiff: add support for subrepo diff
>>>>
>>>>
>>> Maybe extdiff.snapshot() can share code with "hg archive" that supports
>>> --subrepos.
>>>
>>
>> I toyed with a similar idea a year or two ago where the extdiff command
>> basically did 'repo.status -S <pats>' and then 'archival.archive -S -I
>> <what_status_returned>' to build the tree.  If extdiff is taught to use
>> archive -S with the proper matcher, it should be able to handle all
>> subrepos, since they all support archive already, and archive already  
>> knows
>> how to recurse.  (It doesn't look like svn supports status though, so  
>> that
>> may be an archive everything from svn proposition).
>>
> This sounds like a very good idea. Do you still have the code for those
> changes? If not, I'll see if I can take this approach myself (will take  
> me
> a while though).

I see something related at the top of my patch queue.  Let me look it over  
and see if the comments still apply (it's from July 2012, so a lot has  
changed since).

>>
>> The only potential snags I saw were:
>>
>> 1) Archive prints out a message that says "archiving...".  Probably not  
>> a
>> big deal, but a user might wonder why it is archiving.  The progress
>> message archive spits out might be nice for large repos.
>>
> Like you say, it doesn't seem like a major issue. If it's not ideal,
> perhaps I could change the message for extdiff?

Maybe, but I never got to the point of really using it to see if it was an  
issue.  It kinda just felt like I was abusing archive, so I'm glad to see  
others think it is a good idea.


>>
>> 2) Archive supports largefiles.  While this may be useful in some cases,
>> it could slow down building the trees to compare.  I'm not sure if we
>> should have the largefiles extension add a --large to extdiff, and  
>> refactor
>> the largefile overrides for archive accordingly.  I'm looking at
>> refactoring them anyway, since they are mostly a copy/paste of core, yet
>> don't handle everything core does.
>>
> I'll leave this part alone for now, if that's okay, since you mention
> you're looking at refactoring this.

That's probably OK.  The archive command basically works today (though the  
exit code for -I/-X failures doesn't match core, so be aware if you are  
checking exit codes.)  I'm fine with a wait and see approach to the idea  
that you have to opt into largefiles, but make sure that you note the new  
functionality in the commit message when you switch to archive- it's a  
subtle change and other reviewers may have opinions.

>
> Greetings,
> Mathias
>
>>
>> --Matt


More information about the Mercurial-devel mailing list