Should we use subrepos ourselves?

[Brendan Cully]

On Wednesday, 18 August 2010 at 20:34, Patrick Mézard wrote:
> Le 18/08/10 19:00, Brendan Cully a écrit :
> > On Wednesday, 18 August 2010 at 18:49, Patrick Mézard wrote:
> >>>
> >>> I never modify subrepos of thg-winbuild; I'm just collecting the repos
> >>> together to build installers.  And I don't want my pushes to
> >>> thg-winbuild to fail if, for example, the perfarce repo is temporarily
> >>> unreachable.  I also don't want my pushes to take tens of minutes if
> >>> bitbucket is lagging.
> >>
> >> I suppose not pushing if the subrepo current revision is an ancestor of the revision in .hgsubstate or the revision itself, should be enough?
> > 
> > I'm a little worried that this makes assumptions about remote
> > repositories. First of all, obviously this doesn't work if the subrepo
> > URL changes (but I suppose we can catch this).
> 
> Ok, but assuming we are dealing with hashes here, doesn't it mean you just got a collision?

I don't think I follow. We're probably talking about different
things. I just meant that I didn't think it was a good idea to skip
the push if the destination had changed, either because the URL
changed or the repo at the URL changed.

> > But even if the URL
> > doesn't change, you don't know if the repository it points to has
> > (e.g., someone ran strip or restored from backup).
> 
> What's the worse case?
> 
> - If remote was stripped, then you would have pushed the stripped
> - revision again. Instead we no longer automatically restore the
> - subrepo revision and it might break (already broken?) dependencies
> - in the remote parent repo. I would blame the one who stripped the
> - subrepo here.
> - If remote becomes unrelated, then the subrepo push would have
> - failed anyway. If the URL was listed in .hgsub then replacing the
> - repository broke all past .hgsub revisions. Or it was remapped and
> - the problem is dealt with at the parent repo level. If you just
> - introduced the subrepo and the URL was changed before you pushed
> - it, then yes, you are pushing a broken change. 
> 
> Is there anything else?

I don't think it's dangerous, really. But it is (silently) different
from what happens when you push the main repo. We don't expect 'hg
push' from a normal repo to become a no-op when there hasn't been a
commit since the last push.

Maybe the symmetry doesn't need to be preserved, since regular hg push
takes a destination argument that makes skipping a push less
practical, and since I guess we can just go into the subrepo and push
from there. I'm just not sure I'm not personally comfortable with the
silent asymmetry (though I do agree that the extra time taken to do
recursive push is annoying, especially when nothing has changed in the
subrepos). If the consensus is that this special behavior of push for
subrepos is not unnatural, that's fine with me.