[PATCH 1 of 2 STABLE] largefiles: update largefiles in a subrepo when updating the parent

[Mads Kiilerich]

On 01/04/2013 03:42 AM, Matt Harbison wrote:
> # HG changeset patch
> # User Matt Harbison <matt_harbison at yahoo.com>
> # Date 1357181569 18000
> # Branch stable
> # Node ID 5da07921976bf249809cc0934c80c52025cf5e09
> # Parent  cd64a8a2d0da5178de30105ff69ccff32a73a536
> largefiles: update largefiles in a subrepo when updating the parent
>
> Starting with 17c030014ddf, largefiles in a subrepo weren't checked out when
> updating the parent repo.  That cset changed hg.clean() and hg.update() to call
> the newly introduced hg.updaterepo(), and also changed hgsubrepo.get() to call
> updaterepo() directly.  Since only clean and update were overridden, largefiles
> in subrepos were no longer being updated.
>
> The original issue was noticed by Francois Tréton <ftreton at dxo.com> [1].
>
> Unfortunately, this changes the relative order of printing the largefile changes
> and the normal updated/merged/removed/unresolved line, though the actual
> operations remain in the same order.  The alternative is to conditionally call
> hg.clean() or hg.update() in hgsubrepo.get().  However, making the override as
> narrow as possible seems better, and avoids the potential trap of something in
> the future calling an updaterepo() that isn't overridden.

hg.updaterepo doesn't show any status info. It is not so elegant that 
largefiles override it with something that displays status info.

I think I would prefer a simple wrapping of hgsubrepo.get ... if that 
would work. Especially for stable.

(I don't know/remember why hgsubrepo.get ignores the result from 
hg.updaterepo and apparently doesn't show any update status. That seems 
like a bug.)

Do the test in patch 2 cover this change? Then it should be in the same 
patch. (And if not: There should be some test coverage for this.)

/Mads