hg diff in the presence of subrepositories

[paul_nathan at selinc.com]

Martin Geisler <mg at aragost.com> wrote on 06/14/2011 03:37:55 AM:

> From: Martin Geisler <mg at aragost.com>
> To: paul_nathan at selinc.com
> Cc: mercurial at selenic.com
> Date: 06/14/2011 03:38 AM
> Subject: Re: hg diff in the presence of subrepositories
> 
> 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.
> 

Substate describing the *current* substate of the repositories would fit 
the
abstraction presented quite well. Certainly in this scenario, it would fix
the issue. 

I am not sure what else it would affect. 

However, if I understand the hg design correctly, that would require 
diff/status 
traversing subrepositories every time they are called to verify change. 

> > 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.

I'd love to see that come into being. What would it take?

- - -
Regards,
Paul Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110614/b3c5fc43/attachment.htm>