Dealing consistently with subrepositories

[Martin Geisler]

Mads Kiilerich <mads at kiilerich.com> writes:

> On 03/29/2011 11:52 AM, Martin Geisler wrote:
>> 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.
>>
>> What do people think of this grouping? Does it make sense or would you
>> group things differently?
>
> I note that the new ui.commitsubrepos=no also gives a more consistent
> behavior of the commands - but changes it in the opposite direction of
> what you propose here. I think it is fair enough to also get an option
> for increased subrepo recursion. But I also think that it in both
> cases is a property of the subrepo and not a personal setting.

> As you know pull is completely different with and without --update. At
> the same time pull is now a part of update (and of merge, which is
> missing from your list), so you might want to put pull --update in the
> first group as well.

Can we not see 'hg pull --update' as 'hg pull; hg update' with the twist
that the update knows more about where to pull the changesets from? Then
we wont have to discuss both 'pull' and 'pull --update'.

> As you know pull without --update can't be recursive over subrepos
> because it doesn't know what to pull. Incoming do support --subrepos,
> but AFAICS it doesn't give an exact prediction of what will be pulled
> from subrepos - and it can't be done correctly without actually
> retrieving a specific version of .hgsub/.hgsubstate. So yes, these two
> are indeed a special category. They can't be and shouldn't be subrepo
> aware.

It feels wrong to me that incoming supports recursion when pull does
not. Perhaps pull should support --subrepos too and then just do what
incoming does, namely do 'hg pull' in each subrepo. (There is nothing
inconsistent about this, the next 'hg update' will still give you a
consistent state.)

> Update, push and outgoing obviously has to be recursive (and update
> must imply the necessary pulls) and commit has to somehow ensure
> consistency recursively. I think they are a one group of commands -
> and they already have the necessary support for handling subrepos.

Yes, that is true and I also grouped them like that. The missing part is
to make outgoing recurse by default so that it matches push.

> Recursion of commit, status and diff is more debatable and is thus
> IMHO a different group.

True, see below.

> FWIW I still don't understand why commit (and thus status and diff)
> should be recursive by default. Commit obviuosly has to ensure
> consistency so update can restore the exact content, but I don't
> understand why making several commits using the same commit message in
> different repositories is any good.

Oh, you're right, I deleted pat of my argument... at first I figured
that 'commit' must be recursive to ensure consistency, but as you point
out it can also be consistent if it aborts when subrepos are dirty (thus
allowing you to commit from the buttom up).

So that is why I put commit into the 'must recurse' catagory.

But now that I think about it again, then you are right that commit,
status, diff could be non-recursive by default. The problem is then
exactly that commit default to being recursive.


So if we put merge in the group with commit since I guess you could
require people to merge from the bottom up, then this is the revised
categories:

* Must recurse: update <-> add <-> addremove <-> summary <->
  push <-> outgoing

* Could recurse: pull <-> incoming and merge <-> commit <-> status <->
  diff

* Should not recurse: rollback?

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/