<tt><font size=2>Martin Geisler <mg@aragost.com> wrote on 06/14/2011
03:37:55 AM:<br>
<br>
> From: Martin Geisler <mg@aragost.com></font></tt>
<br><tt><font size=2>> To: paul_nathan@selinc.com</font></tt>
<br><tt><font size=2>> Cc: mercurial@selenic.com</font></tt>
<br><tt><font size=2>> Date: 06/14/2011 03:38 AM</font></tt>
<br><tt><font size=2>> Subject: Re: hg diff in the presence of subrepositories</font></tt>
<br><tt><font size=2>> <br>
> paul_nathan@selinc.com writes:<br>
> <br>
> Hi Paul<br>
> <br>
> > I am working to deploy Mercurial in my company using subrepositories<br>
> > to manage our modules, and I am providing support for developers.<br>
> ><br>
> > Our repositories are structured along the lines recommended by
mpm[1].<br>
> ><br>
> > toplevel/<br>
> > ./module<br>
> > ./module<br>
> > ./productcode<br>
> > ./otherproductcode<br>
> <br>
> Sounds good.<br>
> <br>
> > [...] And the conversation continues as I explain the operation
of the<br>
> > .hgsubstate file and how it records the state of the subrepos,
but<br>
> > only on commit.<br>
> <br>
> So I take it that you would also find it natural if Mercurial would<br>
> update the .hgsubstate file *on disk* when it notices that it is out
of<br>
> date with regard to a subrepository?<br>
> <br>
> Right now the .hgsubstate file is written to disk in the middle of
the<br>
> top-level commit and the current content is actually ignored. It would<br>
> make a lot of things more natural if the .hgsubstate file was really<br>
> modified on disk: both 'hg status' and 'hg diff' would suddenly work
out<br>
> of the box with subrepos and you could clearly see what the old and
the<br>
> new subrepo revisions are.<br>
> </font></tt>
<br>
<br><tt><font size=2>Substate describing the *current* substate of the
repositories would fit the</font></tt>
<br><tt><font size=2>abstraction presented quite well. Certainly in this
scenario, it would fix</font></tt>
<br><tt><font size=2>the issue. </font></tt>
<br>
<br><tt><font size=2>I am not sure what else it would affect. </font></tt>
<br>
<br><tt><font size=2>However, if I understand the hg design correctly,
that would require diff/status </font></tt>
<br><tt><font size=2>traversing subrepositories every time they are called
to verify change. </font></tt>
<br><tt><font size=2><br>
> > The problem is:<br>
> ><br>
> > Notice that there is an inconsistency of operation here: hg diff
is<br>
> > not telling the user that there really is a difference in the
world of<br>
> > the top repository. Nor is hg status. Yet, the connotation and<br>
> > denotation of the words say that they tell you the status and
the<br>
> > difference. But they return that there is _no_ difference.<br>
> ><br>
> > While this may make sense from an implementation standpoint (and
it<br>
> > does, if I think like an implementer), I have received this question<br>
> > from multiple people who are experienced, skilled and qualified<br>
> > software engineers who have used other version control systems<br>
> > (ClearCase, SVN, git).<br>
> ><br>
> > From my perspective as a support person for hg in my company,
this is<br>
> > essentially a bug in the user experience and user interface.<br>
> <br>
> I agree with you here, the subrepo UI is still buggy. I've worked
with a<br>
> client to improve this (we got the --subrepos flags added to a number
of<br>
> commands) but it is still not perfect.<br>
> <br>
> The "invisible" .hgsubstate file and the resulting inconsistency
between<br>
> status/diff and commit is probably the biggest remaining problem for
my<br>
> client. We'll probably work on a getting a temporary ui setting into<br>
> Mercurial that will make things consistent, but that is still under<br>
> discussion.</font></tt>
<br>
<br><tt><font size=2>I'd love to see that come into being. What would it
take?</font></tt>
<br>
<br><font size=2 face="sans-serif">- - -<br>
Regards,<br>
Paul Nathan</font>
<br>