[PATCH 1 of 2] subrepo: check that subrepo paths are not existing files

Jordi Gutiérrez Hermoso jordigh at octave.org
Wed Sep 10 13:55:53 CDT 2014


On Wed, 2014-09-10 at 19:31 +0200, Mads Kiilerich wrote:
> On 09/10/2014 04:48 PM, Jordi Gutiérrez Hermoso wrote:
> > On Wed, 2014-09-10 at 01:31 +0200, Mads Kiilerich wrote:
> >> On 09/09/2014 07:56 PM, Jordi Gutiérrez Hermoso wrote:
> >>> # HG changeset patch
> >>> # User Jordi Gutiérrez Hermoso <jordigh at octave.org>
> >>> # Date 1410279390 14400
> >>> #      Tue Sep 09 12:16:30 2014 -0400
> >>> # Node ID 7611a7833657301d9a881095828d5e75558d82f9
> >>> # Parent  897041f6b025778193c6da5b9795da09a91c866e
> >>> subrepo: check that subrepo paths are not existing files
> >>>
> >>> This check has to happen early one, as the .hgsub file is being
> >>> parsed.
> >> Why?
> > Because why not catch an error as early as possible?
> 
> What would happen if we don't catch it?

What happens right now, bug #4363.

> > Currently these problems are caught later after hgsub has been parsed
> > and when attempting to create a subrepo Python object. This is too
> > late, and is the core problem in bug #4363.
> 
> It is not obvious how you get from that bug report to that
> conclusion. 

Running hg in ipdb, basically. It creates a subrepos dict that
includes .hg, and then at the point in which the exception happens
it's iterating through this list before any subrepo object is created.
This list then deletes the ".hg" key at some point, and has extra code
to delete this key again, causing a stack trace. The problem is
obviously (well, obviously to me) that this subrepos list shouldn't be
allowed to contain this list in the first place.

I could add this explanation to the commit message, if you think it's
appropriate.

- Jordi G. H.




More information about the Mercurial-devel mailing list