[PATCH RFC] extdiff: add support for subrepo diff

[Mathias De Maré]

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).

>
> 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?

>
> 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.

Greetings,
Mathias

>
> --Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150208/3c154205/attachment.html>