Overlay repositories

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> 
>>Steve Alexander wrote:
>>
>>>>I want to propose a new feature: Overlay repositories.  That is, a
>>>>repository can point to other repositories, and bzr will use this
>>>>pointer to find the revision data it needs.
>>
>>This sounds a lot like history horizons:
>>
>>http://bazaar-vcs.org/HistoryHorizon
>>
>>The difference is that we wanted to ensure that the repository had a
>>subset of history, and that as long as you stuck to that subset, you
>>could work without connecting to the main repository.

> Steve has the revisions locally, he just doesn't want to have to push
> them to the public location, when they are already available in a
> different public location.

Yes, and the behaviour of Steve's public location is what I considered
similar to history horizons, the difference being that he doesn't even
want the guarantee of having a subset.  He wants ghosts galore.

But history horizons already describes the notion of 'related
repositories', from which ghost revisions may be retrieved.  That seems
to be the core concept of overlay repositories.

> There are a few issues with chaining like this. For example: you are
> probably accessing the branch over sftp, but other people are probably
> more likely to access it over http. Well, for launchpad maybe not, but a
> lot of times there would be a developers location and a public location.
> So now the reference needs to have many different ways of referring and
> indicating to the client which one they should be using.

Possibly.  But it's also a nice idea to allow multiple
'related-repositories' to be specified.  So maybe just specifying the
sftp and http locations would be enough.

> I'd like to think about it a bit, and consider some internals and
> implications. I think we could expand HistoryHorizons a bit for
> something like this.

Yeah, I agree it could be done.  Personally I don't like the notion of
changing bzr so that repositories are constantly dependent on other
repositories that may or may not be accessible.  But this could even be
implemented as a plugin.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFE/hk0F+nu1YWqI0RAia7AJ9cms3jz8oHG7rgs+ob/7RVFGhoJACeJKZl
sC5zksJQSYCSSFrI5YVmSIo=
=ukjT
-----END PGP SIGNATURE-----