[PATCH 0 of 2 STABLE] largefiles: fix status/dirty state interaction with subrepos

Matt Harbison matt_harbison at yahoo.com
Mon Apr 23 00:18:36 CDT 2012


This fixes several issues relating to status and the dirty state of large files
inside a subrepo.  Either patch can stand alone, but since the test updates I
made for the second patch overlaps the first and wouldn't merge cleanly if they
were both based off the current tip, I figured a series would make things
easier.

This is my first attempt at python, and is based more on mimicking how the
extension handles other similar cases than any deep understanding, so if I've
violated some design principle or something, let me know.  All of the tests
that ran prior to these patches also run after they are applied.

As a side note, some of the largefile overrides use a paradigm similar to:

    try:
        repo.lfstatus = True
        return orig(ui, repo, *pats, **opts)
    finally:
        repo.lfstatus = False

I don't understand the mechanism for how the override is called instead of the
original function (I do see the wrap() call that happens).  The question is, if
there are two functions that are overridden in this manner and one calls the
other, does the override for the second get called?  e.g. say dirty() and
status() are overridden, and pretend dirty() calls status() to do its work.  So
the call chain is overriddendirty() -> dirty() -> [overriddenstatus() |
status()]?  The reason I ask is if the override is called, it will clear
lfstatus when it returns, maybe before the original method is ready for it to
be.  Maybe these override methods need to store a local variable that indicates
whether or not they changed lfstatus, and only clear it if they changed it?



More information about the Mercurial-devel mailing list