[Zope3-dev] Re: Version control of ZOPE3 objects

[Tres Seaver]

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

Pjotr Prins wrote:
> Hi,
> 
> I need to build a versioning module for the xParrot project
> (http://xparrot.thebird.nl/). I have some questions and wondered who
> would be inclined to help with the architecture phase.
> 
> The idea is to save objects that implement IVersioning on a
> modification event to either ZODB, or to an external version control
> system like subversion. The latter would be nice as it could handle
> for example diffs through Websvn (a reverse proxy may be needed to
> handle access control through ZOPE). 
> 
> Using an existing version system saves a lot of code and would allow
> for functionality like branching etc. On the other hand commits have
> to be run on a separate thread (which I can model on the current
> mailqueue implementation). Also deployment would require extra
> system administrator skills.
> 
> Before I go down this route I would like to ask if anyone has a
> better idea? And who would take an interest in this little project,
> and doesn't mind bouncing off a few ideas?

Integration with a non-transactional backend (such as Subversion)is
going to be tricky:  the mailqueue, for instance, manages to avoid
re-sending mails for requests which are repeated due to ConflictErrors,
but it can't cope with failure in the actual mail handoff.

In the case of a subversion sandbox, you are going to need some kind of
notification mechanism, at least if each appserver has its own sandbox,
so that you know when to do 'svn up' due to a modification in another
appserver.  You are also going to have to serialize access to the sanbox
between threads in a single appserver.

If a commit fails (e.g., due to a conflict error), it is going to be
tricky for your application to handle:  assuming that you have delayed
doing the actual 'svn commit' to the end of the request (in
'tpc_finish', most likely), then you won't be able to abort the Zope
transaction.  You will also have to come up with UI to allow the user
whose commit failed to resolve the SVN-level conflicts.

I don't know what kind of format xparrot uses for its documents.  Is
it going to be diff-friendly?  If not, then most of the win for SVN is
going to go away.  At that point, I would be considering some kind of
ZODB-based solution, either a content repository (I've done this for
large media sites) or else making the documents themselves into
containers for revisions and drafts (I've done that as well for systems
with fewer, but more complex, documents).


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEsXA2+gerLs4ltQ4RAibxAJ45d4FazCsr30X4qUHDveANoT992ACfU5/w
Vj8UWQYq+KvC0Yeh+80rd40=
=KaYo
-----END PGP SIGNATURE-----