hg diff in the presence of subrepositories

Didly didlybom at gmail.com
Tue Jun 14 06:30:43 CDT 2011

On Tue, Jun 14, 2011 at 12:37 PM, Martin Geisler <mg at aragost.com> wrote:
> paul_nathan at selinc.com writes:
> Hi Paul
>> I am working to deploy Mercurial in my company using subrepositories
>> to manage our modules, and I am providing support for developers.
>> Our repositories are structured along the lines recommended by mpm[1].
>> toplevel/
>>     ./module
>>     ./module
>>     ./productcode
>>     ./otherproductcode
> Sounds good.
>> [...] And the conversation continues as I explain the operation of the
>> .hgsubstate file and how it records the state of the subrepos, but
>> only on commit.
> So I take it that you would also find it natural if Mercurial would
> update the .hgsubstate file *on disk* when it notices that it is out of
> date with regard to a subrepository?
> Right now the .hgsubstate file is written to disk in the middle of the
> top-level commit and the current content is actually ignored. It would
> make a lot of things more natural if the .hgsubstate file was really
> modified on disk: both 'hg status' and 'hg diff' would suddenly work out
> of the box with subrepos and you could clearly see what the old and the
> new subrepo revisions are.
>> The problem is:
>> Notice that there is an inconsistency of operation here: hg diff is
>> not telling the user that there really is a difference in the world of
>> the top repository. Nor is hg status. Yet, the connotation and
>> denotation of the words say that they tell you the status and the
>> difference. But they return that there is _no_ difference.
>> While this may make sense from an implementation standpoint (and it
>> does, if I think like an implementer), I have received this question
>> from multiple people who are experienced, skilled and qualified
>> software engineers who have used other version control systems
>> (ClearCase, SVN, git).
>> From my perspective as a support person for hg in my company, this is
>> essentially a bug in the user experience and user interface.
> I agree with you here, the subrepo UI is still buggy. I've worked with a
> client to improve this (we got the --subrepos flags added to a number of
> commands) but it is still not perfect.
> The "invisible" .hgsubstate file and the resulting inconsistency between
> status/diff and commit is probably the biggest remaining problem for my
> client. We'll probably work on a getting a temporary ui setting into
> Mercurial that will make things consistent, but that is still under
> discussion.

A related issue with this is that if your .hgsubstate file is invalid
for some reason (e.g. it points to a non existing revision on a
subrepo, such as a stripped revision), hg update will fail, even if
you set the --clean flag!

It quite is easy to get into that state if you ever modify your
subrepo history. The parent repo will be unaware of that change and
its .hgsubstate file will point to an invalid revision.

Perhaps if the .hgsubsate file was always consistent this sort of
problem would not happen. Or perhaps mercurial should ignore the
.hgsubstate file when updating (at least with the --clean flag)?


More information about the Mercurial mailing list