Gregoires Versioning Notes

Subversion Integration / Version Control

Note: At the castle sprint, the VersioningTeam worked on these ideas

For those beeing intersted in working on Version Control at the Sprint here are some resources:

1. Project documentation on dev.zope.org: http://dev.zope.org/DevHome/Projects/Wikis/DevSite/Projects/ ZopeVersionControl (under Projects currently on hold on project overview list)
2. Subversion-Documentation on http://svnbook.red-bean.com/

As Limi has stated in

http://sourceforge.net/mailarchive/forum.php?thread_id=3068272&forum_id=8090

we may just work on a more pragmatic implementation.

IMHO during a sprint we should really focus on things where others have already done some work (rule 1) and things we're experienced about (rule 2).

I (gregweb) propose the following:

• There is good Version Control (1.) docu available including interfaces. So we should base on these thoughts and focus on an implementation storing versioning information in the ZODB.
• The interfaces we'll agreeing on should be as general as possible to do a subversion implementation in the future without needing to change them.

Additional remarks to a subversion solution (based on the study of the subversion documentation):

• The actual release of Subversion and also the 1.0 release will only support Copy-Modify-Merge. There isn't/won't be any locking functionality in near future.
• Lock-Modify-Unlock can be simulated by accessing the subversion repository through WebDAV?/DeltaV? implementation of apache. In this case one should not change locked objects by svn blah commands.
• The subversion servers python language bindings seem to be the best available. Accessing the repository server through such bindings cause the same problems as with svn blah.
• A subversion storage should be integrated in Zope as a storage (e.g. using APE which will ship with Zope 2.7).