Dealing consistently with subrepositories

[abn2bf at magic.ms]

Hi Matt, Martin, all,

following the "ui.experimental-subrepo-behavior" switch idea which
should become default in the future - here's what I think is missing
to get closer to a consistent behavior (for the most common commands
so far):

=> Recursive commands The following commands are recursive by their nature in order to
ensure consistency across a hierarchy of repos. We'd need a new 
option to limit their scope to the local repository, e.g.
(-L, --local).

push, pull *), incoming, outgoing, update *), clone (implicitly due
to update), commit, status, add, addremove, move, remove, annotate

=> Non-Recursive commands
The following commands are non-recursive by their nature as you don't
want tags or branches to propagate across repo boarders (in most cases):

tag, branch

"branch -S" might make sense in some cases, usually you'll have local
branch names in your subsystem.

*) Notes on pull/update:
- we have the use case that the system integration team needs to see the
  latest versions of all sub components, e.g. they need a way of recursive
  pulling.
- as push is recursive, it's really hard to teach people that pull isn't,
  e.g. that you cannot see all the recent changesets in subs even if they
  aren't referenced yet by the parent .hgsubstate. (Incoming/Outgoing must
  match Pull/Push).
- I understand that the set of sub repos might change, so you need to keep
  the check on update. Worst case you pull a little too much - therefore
  we need a switch disable the recursive behavior (local scope).

Would you agree to this approach in general? Then we can go forward and
specify/align on the details...

greetinX
/Olaf


-----Ursprüngliche Nachricht-----
Von: "Matt Mackall" <mpm at selenic.com>
Gesendet: Apr 6, 2011 5:38:22 PM
An: "Martin Geisler" <mg at aragost.com>
Betreff: Re: Dealing consistently with subrepositories

On Wed, 2011-04-06 at 10:29 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
>
> > On Tue, 2011-04-05 at 15:13 +0200, Martin Geisler wrote:
> >> Matt Mackall <mpm at selenic.com> writes:
> >>
> >> > On Tue, 2011-03-29 at 11:52 +0200, Martin Geisler wrote:
> >> >> 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.
> >> >
> >> > I've earlier expressed a different rule:
> >> >
> >> > status can't recurse by default until you can use the files it
> >> > outputs with add, remove, commit, etc.
> >> >
> >> > This is what I'm calling 'transparency'.
> >>
> >> Yes, that is a nice notion. But the 'transparency' rule is something
> >> I would use to argue that status must agree with add, remove, commit,
> >> etc.
> >
> > If status shows me file sub/foo, then I should be able to add sub/foo.
> >
> > Today we have third-party tools that assume this. If we change this
> > relationship, tools WILL break. This tells us we're breaking an
> > implicit contract with the user.
>
> Yes, that is one half of what we mean by consistency.
>
> > The converse is not true, because nothing tells a user or a tool that
> > foo/bar even exists. You can quietly make add accept sub/foo and
> > nothing will break.
> >
> > It's not about IF status should be recursive, but WHEN.
>
> Aha... I was indeed questioning *if* it should be made recursive at all.
>
> > And the answer is LAST. If you want to change all the commands at
> > once, I guess that satisfies my requirement, but doesn't strike me as
> > good engineering.
>
> Sure, I'm not talking about any order for the changes, I'm just trying
> to figure out if we can make subrepos consistent at all, for example by
> making some groups of commands non-recursive.

> > Here's another way to think about transparency: status let's you 'see'
> > things, so you now expect to be able to 'touch' those things. But it's
> > not a symmetrical situation, as anyone who's been eaten by a grue can
> > attest.
>
> Hehe :) In this case with add and status, then I do feel that they
> should be consistent: if I do
>
> hg add sub/dir/
>
> then I do want the files under that directory to show up with
>
> hg status
>
> afterwards. It is no good that add work and status doesn't -- maybe for
> scripts, but I want to make it good for humans too :)

Again: if you want to change all the commands at the same time (which is
implicit in saying add and status should agree), that's obviously
possible, but I still think it's bad engineering.

Yes, obviously status and add should agree _eventually_, that's not even
an interesting discussion. The question is how to get from here to there
with the least pain.

--
Mathematics is the supreme nostalgia of our time.