[Zope-CVS] CVS: Products/ZopeVersionControl - CHANGES.txt:1.3
Tres Seaver
tseaver at zope.com
Tue Jan 25 13:03:37 EST 2005
Update of /cvs-repository/Products/ZopeVersionControl
In directory cvs.zope.org:/tmp/cvs-serv24541
Modified Files:
CHANGES.txt
Log Message:
- Further packaging.
=== Products/ZopeVersionControl/CHANGES.txt 1.2 => 1.3 ===
--- Products/ZopeVersionControl/CHANGES.txt:1.2 Fri Jan 30 13:59:39 2004
+++ Products/ZopeVersionControl/CHANGES.txt Tue Jan 25 13:03:37 2005
@@ -1,23 +1,32 @@
-Version 0.3 (not yet released)
+ZopeVersionControl Product Changelog
- - 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:
-
- 1. It required ZopeVersionControl to use the ObjectManager API.
- Version control should not require versionable objects to be
- contained in ObjectManagers.
-
- 2. It assumes that versionable objects are simply wrapped using
- acquisition. References (symlink-like objects) break this
- assumption.
+ ZopeVersionControl 0.3.1 (2004/05/03)
+
+ - 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.
+
+ ZopeVersionControl 0.3 (2004/04/20)
+
+ - 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:
+
+ 1. It required ZopeVersionControl to use the ObjectManager API.
+ Version control should not require versionable objects to be
+ contained in ObjectManagers.
+
+ 2. It assumes that versionable objects are simply wrapped using
+ acquisition. References (symlink-like objects) break this
+ assumption.
More information about the Zope-CVS
mailing list