Zope Version Control
Zope Version Control for the Zope application server.
- Zope trunk compatibility for product init.
- Fix _findModificationTime for ZODB 5 [davisagli]
- Add Support for Python 3 [rudaporto, pbauer, icemac, davisagli]
- Add decode mapping for zodbupdate migration to Python 3.
1.1.3 - 2010-10-02
- Made sure the VersionHistory.BranchInfo class fulfill the API, providing a getId method. Added missing security declarations.
1.1.2 - 2010-08-05
- Made sure we cast MAX32 to an int, as 2**31 would be automatically overflow to a long on 32bit Python’s.
1.1.1 - 2010-08-04
- Made compatible with Zope 2.13 and ZODB 3.10.
1.1 - 2010-07-18
- No changes.
1.1a1 - 2009-11-13
- Fixed an undefined exception.
- Don’t break when checking the connection version in ZODB>=3.9.
- Fixed tests to not use the DemoStorage quota parameter which was removed.
- Changed the Globals.InitializeClass import change in a backward compatible way.
- Fixed deprecation warnings for use of Globals. Specified package dependencies.
- Purge old zope2 Interface interfaces for Zope 2.12 compatibility. Note that they are internal to the implementation of this module.
- Updated package metadata.
- Add omitted ‘tests/common.py’ module.
- __init__.py, nonversioned.py: Fixed compatibility with Zope 2.8 and new-style objects (http://www.zope.org/Collectors/Zope/2137)
- ZopeRepository.py: make ZR addable via GenericSetup toolset (http://www.zope.org/Collectors/CMF/438).
- Utility.py: Import cleanup, including compatibility with ZODB 3.3+ location of ‘refrencesf’.
- IVersionControl.py: Added a module-scope alias for the benefit of older software which depended on the old name.
- Hardened unit tests against the absence of the References product.
Refined the pattern for maintaining parts of objects independently of version control. This is a generalization of the mechanism for versioning container items. IVersionedContainer is now named INonVersionedData and has more descriptive method names.
‘updateResource’ and ‘uncheckoutResource’ now retain the identity of the object being versioned. That is, they never replace an object with a new object, but instead change the state of an existing object.
‘updateResource’ and ‘uncheckoutResource’ used to replace the object in its container, but this strategy had two flaws:
- It required ZopeVersionControl to use the ObjectManager API. Version control should not require versionable objects to be contained in ObjectManagers.
- It assumes that versionable objects are simply wrapped using acquisition. References (symlink-like objects) break this assumption.