[RFC] weave refactoring

[Johan Rydberg]

Martin Pool <mbp at sourcefrog.net> writes:

> Weave could almost implement VersionedFile directly, but perhaps it's
> better to keep just the datastructure in Weave and coordinate with the
> store in WeaveVersionedFile.

Since weave write-outs are now done at transaction commit, we could
let Weave implement all of the VersionedFile, and just let
WeaveVersionedFile add the extra commit and rollback methods.

> I think I'd handle weave merge like this: ask the VersionedFile for its
> representation as a Weave.  (Like asking it for that interface).  Allow
> this to raise an exception if the file is stored in a way that's not
> either a weave or convertible to a weave; this should terminate the
> merge.

Sounds like a good plan.  Next steps would be:

 * Rename Weave to WeaveVersionedFile and let it implement the
   VersionedFile API.

 * Make store.weave.WeaveVersionedFile private to the WeaveStore, and 
   rename it to something else.  Let it only implement the missing
   store-related parts of WeaveVersionedFile.

 * Define an abstract class called Weave, and add a get_weave method to
   the VersionedFile class.


I also would like to give a summary of what I've done so far in my
.versionedfile branch:

 * Introduced the concept of versioned files; implemented using the
   VersionedFile API.

 * Stores for versioned files.

 * Fixed the IdentityMap API by replacing add_weave and find_weave
   with add_object and find_object.  Also added a new
   remove_revision_history method to invalidate cached revision
   history information.

 * Filled in the missing parts of the transaction API and added a
   write transaction.  Let WeaveStore write out weaves on commit.
   This needs a bit more work, and Robert has agreed to review it.

 * Re-worked the transport API to make it more file-oriented. Also
   removed all the _multi-methods.  put and append methods now return
   file-like objects.  All transports except FTP has been adopted.
   Seems to not be any unit tests for the FTP transport.


I also have plans to do the following;

 * Create a new kind of store called RevisionStore which is used 
   to store and retrieve revision information.  

 * Clean up the upgrade code.

 * Clean up the fetcher.

 * (and finally) Add the knit history format.

~j