Dealing consistently with subrepositories

[Patrick Mézard]

Le 29/03/11 11:52, Martin Geisler a écrit :
> Hi Olaf, hi Pradeepkumar, and hi everybody else
> 
> I talked with Olaf about making commands behave consistently with
> regards to subrepos. He works for my client and they are still somewhat
> unhappy with how everything plays together.
> 
> We tried to group the commands based on some invariants. Let us write
> 'foo <-> bar' if 'hg foo' should be recursive if and only iff 'hg bar'
> is also recursive -- it might make sense that none of them are recursive
> but they should agree with each other.
> 
> This defines a number of equivalence classes and I think we came up with
> (Olaf, please correct me if I'm wrong):
> 
> * outgoing <-> push
> 
>   It is normally the case that 'hg outgoing' shows what the next 'hg
>   pull will do.
> 
> * incoming <-> pull
> 
>   While they need not necessarily mirror push and outgoing, incoming and
>   pull should agree with each other.
> 
> * commit <-> status <-> diff
> 
>   I want to be able to see a preview of the next commit with the status
>   command, and if a file is shown as modified by status, then it should
>   also show up in diff (modulo permission changes).
> 
> * commit <-> update
> 
>   Should agree for consistency so that you get back what you commit.
> 
> * status <-> add <-> addremove
> 
>   It is normally so that 'hg add' changes all '?' to 'A' in status,
>   similarly for 'hg addremove'.
> 
> * status <-> summary
> 
>   I think of 'hg summary' as a condensed version of 'hg status'.
> 
> 
> Now, we want 'hg push' to recurse because of safety so that you don't
> push a main repo that referes to a local changeset in a subrepo. So we
> can group the commands like this:
> 
> * Must recurse: update!, commit!, status+, diff+, add+, addremove-,
>   summary-, push!, outgoing+
> 
> * Could recurse: pull-, incoming+
> 
> * Should not recurse: ?
> 
> I marked commands with '!' if they recurse by default, with '+' if they
> support --subrepos, and with '-' if they don't support --subrepos.

What about revert ?

> The idea is to add a setting like ui.consistent-subrepos that when
> enabled makes all the commands behave like above. For some commands such
> as status this just means that --subrepos becomes a default option. My
> client would then enable that option in their system config so that
> everybody sees a more consistent subrepo behavior.

The problem you address is subrepos commands inconsistencies for Mercurial subrepos. I think you should also take in account inconsistencies between subrepository types. When you switch between projects with Mercurial and non-Mercurial subrepositories, or worse when you have different types in a single project, I can imagine such automated behaviours working on half of the subrepositories and failing silently on the other half to cause a lot of headache.

Looking back, adding ui.commitsubrepos was partially driven by svnsubrepos having zero support for diff, status, etc. One solution was to implement all those, which is hard. The other was to make them irrelevant in my workflow.

--
Patrick Mézard