Support for multiple collections in a git repository

[jelmer]

For various reasons, it would be useful to store multiple collections in a single Git store.

This requires per-collection configuration to be moved to a non-.git/config file, per https://github.com/jelmer/xandikos/blob/master/notes/collection-config.rst

[chrysn]

This would be particularly useful when migrating from calypso installations that support this.

The per-collection configuration might be better stored in Vdir-style plain files (as currently spec'd there for color and description).

[jelmer]

Xandikos has gained support for ".xandikos" files since this issue was filed, as an alternative to storing settings in the xandikos section in .git/config

[chrysn]

The support for .xandikos files definitely makes this easier.

I'm looking into what needs to be done to address this, and my current plan would be:

• Create a Store class that is similar to {Tree,Bare}GitStore but also has a prefix parameter; any operation through such a Store object winds up in the represented GitStore under a given path. (Whether that's easiest implemented by subclassing, by creating a wrapper around an existing backend GitStore or by adding a new attribute to GitStore with a default value that represents the tree root is open)
• Make such stores detectable in the listing of collections.
• Optionally, create an (inheritable across the tree, if that's a thing) configuration option that decides whether create_collection returns a TreeGitStore, a BareGitStore or the parent's git store parameterized to select a subtree.

Should I expect any trouble for creating multiple GitStore objects around the same directory (which would be a consequence of the above)? (That might be a similar question as "Should I expect any trouble if someone pushes to my repository while it's running?".)

[jelmer]

I think it makes sense to just add support to the existing Store class - like you say, it could just have a an optional subpath argument that defaults to the root. There isn't much value in subclassing I think, it just adds complexity.

How would you make these stores detectable in the listing of collections? Right now we do very basic url to path translation; you will probably have to actually traverse the filesystem.