supermirror sftp server does not support hosting bzr repositories

[Robert Collins]

This probably needs a spec, but as people usually look at bugs first, I'm starting with a bug.

We should allow people to have a repository at sftp://bazaar.launchpad.net/~ME/PRODUCT. This repository should be autocreated and maintained by the supermirror. It would make making new branches for a user or team much less expensive.

On the publishing side, we dont need a repository as much because we have no lateny. If we decide to do one on the http published content, then the format-changing logic becomes much more complex (see bug: #41414) and also dealing with nuclear launchcode scenarios will become more difficult.

[David Allouche (ddaa)]

Agreed on most of that.

It looks to me like "allow people to have a repository" and "this repository should be autocreated and maintained by the supermirror" conflict.

If we automatically create the repository, it effectively becomes mandatory. It would be more complex to implement and potentially more surprising than just allowing the user to create the repository explicitly.

Also, I see no reason to prevent the creation of a repository in a team context.

So, I'd rather just allow the user to create an explicit repository in ~me-or-team/product, and have the sftp server and and branch puller properly deal with it.

Nice point on the repository not being really needed on the publishing side. But nuclear codes and waste scenarios are also affected by the presence of a repository in the sftp area if the bzrlib fetcher is greedy, and I think it is indeed greedy, at least with weaves.

[James Henstridge (jamesh)]

If anyone does look at implementing this, please keep in mind the branch renaming/reassignment feature of Launchpad.

At present, a user can go to the web UI and rename a branch, assign it to a different product or give ownership to someone else or a team. All of these operations change the path of the branch in the SFTP filesystem. Given that repositories are found by traversing file paths, this makes it very easy for a branch to lose its repository. We would need to make sure that either:
(a) the user couldn't rename branches outside of their repository, or
(b) Launchpad would prime the repository in the new location based on the repository for the old location.

[Michael Hudson-Doyle (mwhudson)]

See https://blueprints.edge.launchpad.net/launchpad-bazaar/+spec/code-hosting-shared-repositories

[Jelmer Vernooij (jelmer)]

this would really help a lot of bigger repositories. I wouldn't consider using launchpad for my Samba branches without this.

[Tim Penhey (thumper)]

Jelmer,

This is happening but not in the simplistic nature originally suggested.

I have renamed the spec that Michael pointed to: https://blueprints.edge.launchpad.net/launchpad-bazaar/+spec/code-hosting-stacked-repositories.

[Jelmer Vernooij (jelmer)]

Ah, thanks. That spec URL appears to require authentication though :-/

[Jonathan Lange (jml)]

Can we close this and say that it's handled in the spec? Alternatively, can we close the spec? Tracking the same thing twice is just unnecessary work.

[Tim Penhey (thumper)]

We are not going to support shared repositories in this manner.

The associated blueprint indicates a better way to get efficient revision sharing.