Tres Seaver <tseaver <at> palladion.com> writes:
> Sharing the blobs using a DVCS pull sounds like an interesting approach.
> One flaw with your outlined implementation is that ZODB blob files are
> *never* updated: rather, if a ZODB object updates the blob object, it
> creates a new blob file and stores its ID. Old blob files are cleaned
> up during a pack.
Interesting. You know what git does? If one adds a file X (actually git deals
with contents not files) to the repository, git computes a hash value (sha1) and
uses that value as the name for the file. It's stored under the .git directory.
Some update of bookkeeping data and that's it.
If the contents of the file X changes, and it is committed to the git
repository, git computes a sha1 and stores the new content under that new sha1
name + updating of the bookkeeping. The old file is not deleted. Git does not
even bother to compress anything. That would be done by an additional "git gc".
In contrast to most other SCMs git can be considered as a database. That git is
mostly recognized as a version control system, is only half of the story. The
underlying storage system is what make git so interesting.
I have no good knowledge of zodb and you are certainly doing great with it, but
my concern is with the blobs (which as I hopefully understand correctly are to
be stored outside of Plone's Data.fs).
Storing versions of files into a DVCS is like freeing the zodb (for blobs) from
doing its own versioning.
Actually, I think conceptually git and the zodb are quite similar. One
transaction is nothing else than a commit in the SCM sense.
> If you want to experiment with the idea anyway, then writing a "wrapper"
> storage is probably the way to go: DemoStorage is one such beast, as is
> the BlobStorage itself.
I'm sorry, I cannot do this. I've simply no time for opening up another area of
development for me.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org