[PATCH] subrepo: handle missing subrepo spec file as removed

Kevin Bullock kbullock+mercurial at ringworld.org
Thu Nov 18 11:55:26 CST 2010


On Nov 18, 2010, at 2:08 AM, Martin Geisler wrote:

> Patrick Mézard <pmezard at gmail.com> writes:
> 
>> Le 17/11/10 22:27, Patrick Mezard a écrit :
>> 
>> [...]
>> 
>>> +delete .hgsubstate and update
>>> +
>>> +  $ hg up -C
>>> +  warning: subrepo spec file .hgsub not found
>>> +  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>>> +  $ rm .hgsubstate
>>> +  $ hg up 0  
>>> +  remote changed .hgsubstate which local deleted
>>> +  use (c)hanged version or leave (d)eleted? c
>>> +  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>>> +  $ hg st
>>> +  $ ls subrepo
>>> +  a
>> 
>> The test is interesting because it highlights .hgsubstate magical
>> behaviour: it is first deleted, then on the update the merge machinery
>> kicks in and eventually merge it by restoring and overwriting it.
> 
> Interesting... the .hgsubstate file is in many ways a ghost file: it is
> written or updated just before commit so 'hg status' or 'hg diff' will
> not reveal the pending change, and yet the file is there in the next
> changeset. I think "magic" is just the right word to describe it :)
> 
>> Also, I am not sure what to expect in the update case:
>> 1- The current situation where the missing .hgsub spec is apparently
>> ignored (I admit I have not investigated the reasons for the merge
>> result)
>> 
>> 2- A situation where the missing spec file is considered removed and
>> act accordingly. But if .hgsub is there and .hgsubstate is missing,
>> what should be done?
> 
> Both of these situations are inconsistent and broken -- it is part of
> the design of subrepos that there must always be a .hgsubstate file if
> there is a .hgsub file, as I know you're aware.
> 
> But when there is a .hgsub file and no .hgsubstate file, then I would
> expect Mercurial to behave like it does when you first add a .hgsub
> file: there you have no .hgsubstate file and it is automatically built
> on the next commit.
> 
> When .hgsubstate is deleted in revision 2 and you updated to revision 1
> and leave it deleted, then I guess the subrepos should be left in the
> state they were in before the update. The next commit will then record a
> .hgsubstate file that looks like the deleted one from revision 2.

It strikes me that this could be handled similarly to how tags are read—by reading .hgsub and .hgsubstate them from the repository instead of the dirstate (though not across all heads, of course). Unless this is how it's already done? But it seems that the only reliable checkpoint for subrepo state is that in a recorded commit.

If I removed .hgsub and updated to a prior revision that had it, I'd expect the .hgsub from the _target_ revision to be used. I think we could just establish by fiat that working dir changes to .hgsub are not merged on update.

>> Not sure all this really matters now, my initial issue was to avoid
>> "breaking" the working directory.
> 
> Yes, I agree that is more important.

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



More information about the Mercurial-devel mailing list