[PATCH 3 of 6] hg: replace repository(remoteui) with peer()

[Peter Arrenbrecht]

On Mon, Jun 13, 2011 at 6:19 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2011-06-13 at 13:31 +0200, Peter Arrenbrecht wrote:
>> On Mon, Jun 13, 2011 at 12:04 AM, Matt Mackall <mpm at selenic.com> wrote:
>> > On Wed, 2011-06-08 at 18:45 +0200, Peter Arrenbrecht wrote:
>> >> # HG changeset patch
>> >> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
>> >> # Date 1307550324 -7200
>> >> hg: replace repository(remoteui) with peer()
>> >
>> > I've spent a while poking at this; looks like refactoring things into a
>> > state where they can be finished before the 1.9 freeze isn't going to
>> > happen.
>> >
>> > My goal is to have peer.local() return a repo object if one is available
>> > and to have no method going the other way.
>>
>> Yes, that makes it quite a bit harder if you still want to aim for
>> peer and repo having different method names to ensure we don't
>> accidentally use a repo where we should use a peer, and vice versa. I
>> guess it essentially means code like the one in transplant will have
>> to keep track of the peer associated with "source" by itself, instead
>> of being able to just call source.peer() where needed. I can see how
>> not having .peer() forces users to more clearly think about peers and
>> repos, instead of simply using .peer() and .repo() to switch
>> willy-nilly. But maybe our review process would be enough to avoid
>> that?
>
> The thing is that this should actually make things a lot simpler.
>
> There's very little code that legitimately has a reason to poke at two
> repo objects. So you generally have either:
>
> - your local repo as given to you by dispatch
> - your local repo plus a peer object you create
>
> The only code I'm aware of that needs anything different is:
>
> - transplant (yuck)
> - clone has three cases:
>  - local to local (hardlink clone)
>  - peer to local
>  - local to ssh
>
> To fix up this latter case, we simply make everything work in terms of
> peers and then break up the cases thusly:
>
> if src.local() and dst.local():
>  # hardlink
>  srcrepo = src.local()
>  ...
> elif dst.local():
>  # clone to local
> elif src.local():
>  # try to clone to (ssh) peer
> else:
>  # abort - can't do remote-to-remote clone
>
> Transplant is basically the same story.

Actually, transplant could just call localpeer(source) as needed,
instead of relying on source.peer(). It knows that source is a local
repo, after all, and it really needs a local peer to pass to pull.
This would get rid of the annoying "peer.peer(self): return self"
thingy and still be easy on transplant.
-parren

>> I guess this also means we still don't have a proper place where
>> batching can be added. I could simply add it to wirerepo for now and
>> only use it in discovery if the capability is supported, which
>> localrepo would not. My goal is to have batching support in servers in
>> 1.9 if at all possible.
>
> Ok, start sending me the basics.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>