[MERGE] Add simple Storage object

[Aaron Bentley]

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

Hi all,

This patch adds the concept of a Storage object to Repositories.  When
fully complete, the Storage object will act as the minimum interface
required to implement new repository types.  This would include support
for the VersionedFile API.  Essentially, StorageRepository and
StorageVersionedFile would become adaptors.

RemoteRepository
================
Our current implementation of RemoteRepository falls back to its
virtual-filesystem layer for many of its operations.  This means it is
slower than it has to be.

Supporting a VFS means that write operations are dangerous; a user can
write data into a repository that makes the repository corrupt.
Implementing all operations in terms of a Storage object would allow us
to drop support for vfs operations, which would make it impossible for a
user to corrupt the format of a repository.  They could still commit bad
revisions, of course.

Because the RemoteRepository is conceived as different-in-kind from the
transport-based Repository types, it does not derive from Repository.
But this leads to increasing amounts of duplicate code.  If Repository
were implemented in terms of Storage, then only the Storage object would
be different-in-kind, and RemoteRepository could be a subclass of
StorageRepository.  (Presumably, RemoteRepository would still implement
optimizations that apply only to remote operation.)

StackedRepository
=================
AIUI, the current plan for StackedRepositories is to implement stacking
at the pack level.  This is an expedient way of doing it.

But if Storage provides a simple API, then it would be easy to implement
StackedStorage on top of it.  This would allow all repository types to
be stacked, not only pack repositories.

It would also be possible to stack bundles on top of repositories,
allowing merge directives to behave more like branches.

In fact, we could even stack WorkingTrees on top of repositories, the
same way they are used to accelerate build_tree.  But Storage should
provide an optimal implementation of iter_files_bytes, so I expect it
would not be useful.

Database-backed repositories
============================
It might or might not be useful, but it would sure be neat.


Planned API
===========

get_raw_items()
  implemented in the patch

insert_raw_items()
  insert raw entries into the underlying storage.

iter_byte_streams()
  like iter_files_bytes, except that it can address revisions,
  inventories, and signatures as well as files.  Implemented on top of
  get_raw_items using a Builder object

insert_byte_streams()
  Creates new versions of items such as files, revisions, etc.
  Essentially the complement of iter_byte_streams for writing.

iter_annotated_byte_streams()
  Not sure about this one.  Presumably it would just use a different
  Builder.

get_parents_map()
  The same as the ParentsProvider concept, but applied to any graph--
  file, inventory, revision, signature.

_get_build_parents_map()
  Similar to the above, but applied to the build dependencies of the
  item, rather than its logical parents.  I think this is only needed by
  item Builders, so we can keep it out of the public API for now.

find_branches
  The same as the Repository version

The Repository set of lock functions:
lock_read
lock_write
is_locked
is_write_locked
unlock

The Repository set of write_group functions
start_write_group
abort_write_group
commit_write_group
is_in_write_group

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

iD8DBQFHnPPY0F+nu1YWqI0RAp00AJwNCQxdqtw7A+OctA7x4NGasZmccwCdGK5Q
FAqYNq1bTP9ARfx9nxhi4jA=
=HKiL
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bzr-mail-09rkLx.patch
Type: text/x-diff
Size: 26336 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080127/b6b8c8ab/attachment-0001.bin