adding the repo to dispatch.request + command server thoughts

[Matt Mackall]

On Sun, 2011-05-29 at 23:21 +0300, Idan Kamara wrote:
> Hi,
> 
> I'm thinking on how to add the repo object to dispatch.request.
> 
> Some background: lets assume that the command server answers queries of the
> form "<path>:<args>", where <path> is an existing path to a repository.
> Internally, it will have a mapping of <path>:<cached stuff>, where cached
> stuff will include the repo/ui objects and possibly other cache worthy
> things.
> Once a command arrives, the server checks if <path> exists, and if so it
> uses the cached repo object by placing it in the request object passed to
> dispatch.

I think the easiest way to do this is for clients to specify a repo per
connection:

import hgcmdserver

c = hgcmdserver.open("myrepo")

..which translates to calling:

hg -R myrepo serve --cmdserver


Now, if someone wants to do:

c.rawcommand(['-R', 'someotherrepo', 'st'])

..that's not going to be cached, but will still do the right thing.


Then the server needn't worry about all the issues involved in managing
a long-lived cache of potentially large repo objects. That complexity
can be pushed up to whatever silly app wants to talk to N repos
simultaneously.

> The tricky part is -R might be one of the <args>. We'd like to pull the repo
> object specified by that, rather than the one by <path>, so looking at
> <path> won't always work..
> The logic for inferring the path is in dispatch._dispatch, it does this
> roughly:
> 
> 1) get -R/--repo/--repository from the args
> 2) find a .hg dir in the cwd, cd'ing up if necessary (this is done even if
> (1) returned something, to build the local ui)
> 3) try to build a repo object from the result
> 4) if (3) fails, try to guess a path from the args
> 
> Instead of somehow imitating that in the command server, I think a
> getrepo(path) function on the request object for _dispatch to use could work
> better.
> 
> Also to consider is the working directory. The command server should
> probably chdir to <path> before calling dispatch so things like relative
> paths work as expected.
> Another thing is the local ui, I'd like to keep that in the cache as well.
> 
> Here's how a query to cmd server might look like:
> 
> query <"/repos/foo":"-R ../bundle log"> sent to the cmd server ->
> chdir "/repos/foo" ->
> check if "/repos/foo" is in the cache (for the ui objects, the repo is not
> pulled now) ->
> suppose it's not, call dispatch.dispatch, with the args ->
> dispatch creates ui, lui objects, puts them in the request before modifying
> them (via --config for example) ->
> dispatch infers "/repos/bundle" to be the path to the repository ->
> calls request.getrepo("/repos/bundle") -> returns None ->
> creates a bundlerepository ->
> puts it in the request, with the inferred path ->
> runs command, dispatch returns ->
> cmd server checks if it already has a repo/ui for the inferred path, since
> it doesn't it takes them and puts them in cache
> 
> Next call with cache being hit:
> 
> query <"/repos/foo":"-R ../bundle log"> sent to the cmd server ->
> chdir "/repos/foo" ->
> check if "/repos/foo" is in the cache ->
> it is, call dispatch.dispatch, with the args + ui ->
> dispatch infers "/repos/bundle" to be the path to the repository ->
> calls request.getrepo("/repos/bundle") -> returns a bundlerepo ->
> runs command, dispatch returns ->
> cmd server checks the cache for the inferred path, doesn't set anything
> 
> It's a bit rough, but that's what I have in mind atm.
> 
> Opinions are appreciated, thanks.


-- 
Mathematics is the supreme nostalgia of our time.