[PATCH] Tweaks to subrepository-related output

[Steve Borho]

On Thu, Jun 18, 2009 at 4:56 AM, Matt Mackall<mpm at selenic.com> wrote:
> 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.)

This is also begging for some enterprising person to add a database
implementation that solves the 'large binary' problem that many people
evaluating Mercurial get hung up on.

--
Steve Borho