views:

62

answers:

1

I've got a Mercurial repo set up like this, with a subrepo inside another subrepo:

Root 
  .hg 
  .hgsub 
  .hgsubstate 
  Nested
    .hg 
    .hgsub 
    .hgsubstate 
    foo.txt 
    FurtherNested 
     .hg 
     bar.txt

If I change foo.txt and bar.txt and commit from inside Root then all is well and all the nested subrepos commit. However if I only change bar.txt and commit from Root then Hg thinks nothing is changed. I have to commit from inside Nested to get the FurtherNested changes to commit when there are only changes in FurtherNested. It seems that in order for nested subrepos to work, each nested level has to contain changes in order for the recursion to work.

Nothing I read in the Mercurial docs on subrepos seemed to imply that subrepo commits would only propagate if there were changes. In fact it says the opposite:

When we commit, Mercurial will attempt to recursively commit in all defined subrepos...

So my question is, is this to be expected or is something broken or just not done yet (Mercurial 1.5.4 on Windows)?

A: 

Looks to me like this is just something that's broken. The relevant source code (in subrepo.py) doesn't seem to recurse into subsubrepos, viz:

def dirty(self):
    r = self._state[1]
    if r == '':
        return True
    w = self._repo[None]
    if w.p1() != self._repo[r]: # version checked out change
        return True
    return w.dirty() # working directory changed

Probably wouldn't be too hard to fix, though I don't know the code intimately enough yet. It would probably be worthwhile posting on the [email protected] mailing list and/or filing a bug. I doubt Matt and Benoit are reading this, but they definitely do read everything posted there.

Alistair Bell
So, to follow up, as you discovered by posting on the mailing list, this was fixed in 1.6 by changing the behavior of w.dirty(). My bad for not thinking that they might have captured this inside 'did the working directory change?'.
Alistair Bell