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

[Matt Mackall]

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.

> 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.