the issues of the hard enforced state of subrepos

Kevin Bullock kbullock+mercurial at ringworld.org
Tue Nov 9 14:11:24 CST 2010


On Nov 9, 2010, at 11:48 AM, Ronny Pfannschmidt wrote:

> After having quite some issues with a hg repo that has now broken
> subrepo state metadata i would like to bring up a discussion on enabling
> one to disable those enforcements.

I'd be more interested in seeing hg gracefully handle a broken state (and prevent creating one to begin with) rather than just blanket turning off the consistency requirement.

> I'm my particular case hg refused to check out any other revision
> without a cycle of killing the subrepo state metadata files, marking
> them as removed and doing a forced update (up -C).

Would your situation have been fixed by having `update -C` only check that the _target_ rev's subrepo state was consistent, ignoring the working dir's .hgsubstate? I don't know the subrepo code, just trying to understand your issue more specifically.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock

> I think this clearly shows that once consistency is broken anyway,
> trying to enforce does more harm than good.
> 
> My suggested solution would be to enable users to enable/disable subrepo
> handing on a per repo basis.
> 
> As far as I remember Git handles its own submodules as disabled/ignored
> till the feature gets enabled, and given my recent negative experience
> with subrepos trying to be consistent even when they cant i consider the
> possibility to opt out the superior behaviour.
> 
> regards, Ronny
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list