-----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 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v18.104.22.168 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsXA2+gerLs4ltQ4RAibxAJ45d4FazCsr30X4qUHDveANoT992ACfU5/w Vj8UWQYq+KvC0Yeh+80rd40= =KaYo -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com