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