[PATCH] Tweaks to subrepository-related output

[Matt Mackall]

On Thu, 2009-06-18 at 11:28 +0200, Dan Villiom Podlaski Christiansen
wrote:
> On 18/06/2009, at 10.46, Martin Geisler wrote:
> 
> > Dan Villiom Podlaski Christiansen <danchr at gmail.com> writes:
> >
> >> diff --git a/mercurial/commands.py b/mercurial/commands.py
> >> --- a/mercurial/commands.py
> >> +++ b/mercurial/commands.py
> >> @@ -2300,6 +2300,13 @@
> >>     URLs. If DESTINATION is omitted, a default path will be used.
> >>     See 'hg help urls' for more information.
> >>     """
> >> +    # push subrepos depth-first for coherent ordering
> >> +    c = repo['']
> >> +    subs = c.substate # only repos that are committed
> >> +    for s in sorted(subs):
> >> +        if opts.get('rev'): raise NotImplementedError()
> >
> > I don't know why you raise this exception, but it should just be
> > NotImplementedError without the parenthesis.
> 
> Erm, it was mainly because the revision isn't handled. Perhaps a  
> warning would be better?

We tend to use util.Abort(). That distinguishes Mercurial issues from
Python and library issues at higher levels.

But it's not at all clear what the right thing to do with push -r is, so
without an actual discussion/rationale, it's premature to change the
behavior.

> For what it's worth, I have update and pull (mostly) working locally :)

It's also not clear what pull should do. Pull is defined in terms of
repository history while subrepos are defined in terms of the contents
of csets (specifically .hgsub/.hgsubstate). Specifically, pull say 'give
me all history remote has that I don't have'.

So to do pull 'right', we'd have to inspect all copies
of .hgsub/.hgsubstate in history and pull all the subrepos defined
therein. The current 'lazy' approach to pulling subrepos avoids this
problem by only pulling a subrepo when we don't have the relevant
revision.

It's also important to bear in mind that the whole subrepo design
assumes that the subrepo might not be native to Mercurial and may not
even have a notion of push and pull. Perhaps I should actually implement
SVN support just to make this more obvious.

(Of course, I encourage someone else to tackle this particular
challenge. The hgsubrepo object in subrepo.py is only 70 lines. The most
straightforward svnsubrepo object using os.system should be comparable.
Similarly for git.)

-- 
http://selenic.com : development and support for Mercurial and Linux