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:
- 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)
- Subversion-Documentation on http://svnbook.red-bean.com/
As Limi has stated in
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
- 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
- A subversion storage should be integrated in Zope as a storage (e.g. using APE which will ship with Zope 2.7).