[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion efficiency while handling Zope Data.fs files?

From: Marcin Kasperski <Marcin.Kasperski_at_softax.com.pl>
Date: 2004-04-14 19:15:56 CEST

> > Has anyone tried using subversion for backup and versioning
> > Zope Data.fs files? How efficient is this?
> That's funny. I *just* started teaching myself Zope over the
> weekend, and was wondering about similar things: how does one
> version control a Zope application?

IMHO the troubles with version control are among main drawbacks
of Zope. In fact, it seems that most people live with Zope
internal versions mechanism and store somewhere Data.fs every
time they decide to pack the database.

I remember some kind of CVS plugin for Zope but (at least when I
reviewed it some time ago) it was tended to the 'operate on
single file/object at the time' concept, without natural
support for commiting/updating the whole trees.

> I've been wondering if it makes more sense to export an entire
> "Zope folder" as XML, and keep that huge XML file (which
> contains everything: python code, data objects, page
> templates, all directory structure) in a Subversion
> repository.

You could. You could also probably use Zope XML-RPC access to
write python scripts which would perform the whole task.

There is also some interesting experiment one could perform. Zope
has layered architecture with fairly well separated database
handling code and multiple implementations of database interface
(in Zope slang called 'Storage'). Apart from the standard
storage (Data.fs) there are storages using BerkeleyDB, Oracle
and even filesystem-based DirectoryStorage.

I could imagine someone attempting to write Zope storage based
on ... Subversion repository.

> > versioning Data.fs can mean scenario like: we have 50MB
> > binary file, 500 times a day something appends new 50, 100
> > or 500 bytes at the end of it.
> >
> > How efficient can be commit in such a scenario?
> Well, that means that 'svn commit' will only send the newly
> appended data to the repository. And that same binary-diff
> will be used to store successive revisions of Data.fs in the
> repository. The fact that Data.fs is binary is irrelevant;
> Subversion treats all files and diffs as binary.

... and the question is how efficient will be the diff

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 14 19:17:30 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.