shared storage and branch api

[Aaron Bentley]

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

Robert Collins wrote:
> While I was writing an external test for 'is foo merged fully into bar',
> I realised that all the shared storage proposals so far will add some
> complexity:
> 
> Currently, its true that if a revision-store has a revision, that
> revision is merged into the branch

No, that's not currently true, and I've never inteded it to be true.
The uncommit command, for example, will remove revisions from a tree
without removing them from the store.

If you want to know what's been merged, you need to make an ancestry graph.

, and conversely, if
> branch.get_revision fails, its not in the store.

This one is true, but it doesn't mean that a revision has not been
merged into a branch.  The model does permit missing ancestors.  We're
missing revision-history ancestors as errors, though.

> A shared store of any sort will make that only sometimes true. I haven't
> really thought about the implications in design yet, just thought I'd
> raise it now for consideration.

So since the guarantees you thought were there about stores were never
there, I don't think they'll cause a problem when we move to supporting
shared storage.

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

iD8DBQFDHZJ/0F+nu1YWqI0RAtSlAJ0TMqAYSyK2QKM8P4fjpyWffF15sQCfZSfo
XxmOZLk7ao02Yt694BJqVrc=
=vVRh
-----END PGP SIGNATURE-----