[PATCH RFC] repo: differentiate between repos and proxies for potentially remotes

[Peter Arrenbrecht]

On Mon, Jun 6, 2011 at 8:28 PM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> On Mon, Jun 6, 2011 at 7:25 PM, Matt Mackall <mpm at selenic.com> wrote:
>> On Sat, 2011-06-04 at 14:05 +0200, Peter Arrenbrecht wrote:
>>> On Fri, Jun 3, 2011 at 9:41 PM, Matt Mackall <mpm at selenic.com> wrote:
>>> > On Fri, 2011-06-03 at 20:37 +0200, Peter Arrenbrecht wrote:
>>> >> # HG changeset patch
>>> >> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
>>> >> # Date 1307126195 -7200
>>> >> # Node ID 063cd4fae0ee0606678ed22dbaf1c77948301662
>>> >> # Parent  1ffeeb91c55d0b00445ceabde14a0d0faf906a33
>>> >> repo: differentiate between repos and proxies for potentially remotes
>>> >>
>>> >> Currently, there is no clear distinction between working with a
>>> >> known-to-be local repo and proxies for remote repos. So if tests don't
>>> >> actually exercise code that could accept remote proxies with actual remote
>>> >> repos, we won't catch improper calls.
>>> >>
>>> >> This patch introduces localproxy, which has basically the same contract
>>> >> as wirerepository, but for localrepository instances. Commands which want
>>> >> to work with possibly remote repos now have to use hg.repoproxy() instead
>>> >> of hg.repository(). The latter newly enforces that it only returns local
>>> >> repos.
>>> >>
>>> >> I also split the local proxy into localproxy and localwireproto. The
>>> >> former only exposes the most modern methods to ensure that these are the
>>> >> only ones used against servers supporting the most modern set.
>>> >>
>>> >> Then there is localwireproto which adds in the legacy commands so the
>>> >> server can still expose them to older clients.
>>> >>
>>> >> The last change in sshrepo.py actually fixes a bug with new hg against
>>> >> old ssh servers (those not supporting unbundle), I think.
>>> >
>>> > This is quite a big patch, is there a way we can split it up into
>>> > smaller steps?
>>>
>>> I guess I can do the following steps:
>>>
>>>  * sshrepo fix (should have been separate anyway)
>>
>> Good.
>>
>>>  * make all users go through repo.capable() instead of .capabilities
>>
>> Good.
>>
>>>  * turn repo.capabilities into repo._capabilities()
>>
>> ?
>
> Makes it easier to override. I had some trouble getting the notcapable
> script in the tests to work.
>
>>>  * factor legacy support out of localrepo into localwireproto
>>
>> Sounds reasonable, but I'm not completely sold on the name. Is there a
>> reason it shouldn't just end up in wireproto.py?
>
> It easily could. I just thought keeping it close to localrepo and
> localproxy was handy.
>
>>>  * introduce hg.repoproxy and make callers use it appropriately
>>
>> Not sure I like this naming. Proxy isn't really the right term. It's
>> more like an RPC interface. And it's not even that for the localrepo
>> case.
>>
>> I think I'd actually prefer hg.remoterepo(). Given that we're doing this
>> all over the place:
>>
>> mercurial/commands.py:    repo = hg.repository(hg.remoteui(ui, opts),
>> repopath)
>>
>> ..we can turn that into:
>>
>> remote = hg.remoterepo(ui, opts, repopath)
>>
>> ..and make the remoteui magic happen internally. In fact, I think we
>> could just call the whole concept a 'remote':
>>
>> remote = hg.remote(ui, opts, remotepath)
>
> This sounds good, except that localremote sounds a bit unusual. Shall
> ping you on IRC about this.

For the record, we decided to use hg.peer(), localpeer, httppeer, etc.
-parren

>> This should be moved up the stack one level, as it's not actually
>> dependent on refactoring localrepo.
>
> Sure. Though it already is above the actual refactoring of localrepo
> into localrepo and localproxy.
>
> Shall also address Adrian's findings.
> -parren
>