Merge lp:~cjwatson/turnip/auto-create-repository into lp:turnip

I was thinking that this could instead be done by Launchpad inside translatePath if it knows it hasn't created it yet. What do you think about that?

When trying to implement William's suggestion, I found that indeed it's quite reasonable for Launchpad to take care of creating a GitRepository row when asked to translate-for-writing a well-formed path it doesn't know about yet, but it's still useful for turnip to deal with the "git init" bit when trying to receive into a repository path that doesn't yet exist on disk. This makes the interface between Launchpad and turnip much simpler when creating repositories.

I've amended this branch with this new approach.

On 14/02/15 05:28, Colin Watson wrote:
> When trying to implement William's suggestion, I found that indeed it's quite reasonable for Launchpad to take care of creating a GitRepository row when asked to translate-for-writing a well-formed path it doesn't know about yet, but it's still useful for turnip to deal with the "git init" bit when trying to receive into a repository path that doesn't yet exist on disk. This makes the interface between Launchpad and turnip much simpler when creating repositories.
>
> I've amended this branch with this new approach.

Will that still be useful when 99% of created repositories want to be
forks of existing ones, rather than fresh inits?

It probably won't be *useful* in that case, but also not harmful; I mean, if we have to do something first to fork the repository, then we have to do that no matter what, right?

On 14/02/15 20:34, Colin Watson wrote:
> It probably won't be *useful* in that case, but also not harmful; I
> mean, if we have to do something first to fork the repository, then
> we have to do that no matter what, right?

If we run into this case on production it must indicate a bug, and
rather than reporting a problem it will just silently do the wrong thing.

In what case would this be useful in a real environment? Also remember
that we currently have no local state except the repository, but that
will eventually change, at which point implicit creation on ENOENT
becomes less desirable.

I would have Launchpad's translatePath create the LP GitRepository and
then call into turnip to create the repo.

I think I was misled by your comment on https://code.launchpad.net/~cjwatson/launchpad/git-namespace/+merge/248995 where you said "We might also be able to get away with doing this on the first repository access" into thinking that we could do part of it on the first access *in turnip*, and didn't think properly about the state requirements. Fair enough; I'll withdraw this MP, and include GitHostingClient again in Launchpad when I get far enough up the stack to have the XML-RPC service code.

Ah, sorry, that was ambiguous indeed. I was meaning something sort of like the PPA key generation situation: we may assume that some reasonable subset of created repositories will never be accessed, so it may make sense to lazily create the turnip side of things. If we were to do that, LP's translatePath would notice that it has a GitRepository row but doesn't exist in turnip, and make the same call into turnip as it would if the GitRepository didn't exist. But Git repositories are cheaper than OpenPGP keys, so it may not be sensible to delay that except for app performance reasons.