is there a current maintainer or development process for ZopeVersionControl? there's been a little bit of activity lately, but it's still in CVS. in any event, CMFEditions (a versioning system for Plone) depends on ZVC, and it seems that some recent changes to Zope's DateTime implementation have caused a ZVC bug to come to the surface. dorneles has recently improved the ISO8601 support in the DateTime module (http://tinyurl.com/y9weck). one of the results is that DateTime('1') now is interpreted similarly to DateTime(1), whereas before it would raise an error. in ZVC's Repository.getVersionOfResource() method (http://tinyurl.com/yab2xw), a selector is passed in, which the method will try to use in a number of ways before deciding that there's no matching version to return. the final test looks like this: try: date = DateTime(selector) except: raise VersionControlError( 'Invalid version selector: %s' % selector ) else: ... RETRIEVE BY TIMESTAMP HERE thus the change in DateTime behaviour means if the selector is a string representation of an integer, it formerly would have been rejected as invalid, but now will be considered a timestamp lookup. since version ids are commonly string representations of integers, this can be a bit of a problem. i'm not sure whether the DateTime behaviour should be reverted, or if there should be a change in ZVC. and i'm also not sure what's going on w/ ZVC's maintenance... are there any plans to bring it over to subversion? i'm happy to commit a fix, if someone can point me in the right direction. thx, -r
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13 Dec 2006, at 03:44, Rob Miller wrote:
is there a current maintainer or development process for ZopeVersionControl? there's been a little bit of activity lately, but it's still in CVS.
in any event, CMFEditions (a versioning system for Plone) depends on ZVC, and it seems that some recent changes to Zope's DateTime implementation have caused a ZVC bug to come to the surface. dorneles has recently improved the ISO8601 support in the DateTime module (http://tinyurl.com/y9weck). one of the results is that DateTime('1') now is interpreted similarly to DateTime(1), whereas before it would raise an error.
ZopeVersionControl has no official maintainer. The DateTime implementation has problems and needs to be fixed, at the very least for those problems that cause failing CMF unit tests right now. Dorneles said he would do it but hasn't gotten to it yet. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFf7LgRAx5nvEhZLIRAgUFAKCCgVQQEXsFCdRHC4dHmU4Mt6GL2gCeKmux vimAUDVO0QK5RWiSnWJJC5A= =tmEM -----END PGP SIGNATURE-----
Hey Rob, folks,
in any event, CMFEditions (a versioning system for Plone) depends on ZVC, and it seems that some recent changes to Zope's DateTime implementation have caused a ZVC bug to come to the surface. dorneles has recently improved the ISO8601 support in the DateTime module (http://tinyurl.com/y9weck). one of the results is that DateTime('1') now is interpreted similarly to DateTime(1), whereas before it would raise an error.
thanks for the pointer! There was no tests for that behavior before... I'll add a few ones to make sure this won't break again. BTW, ISO8601 allows us to specify dates using only the year (or year and month; or even only the century) and thus '19', '1900', '1900-01' and '1900-01-01' will all be parsed as DateTime('1900/01/01'). What do you guys think about those specific cases? Does it break BBB compatibility and should not be supported by the ISO8601 parser at all? If so, please tell me, as I'm in middle of the process to fix the ISO8601 parser to make everyone happy... :-)
in ZVC's Repository.getVersionOfResource() method (http://tinyurl.com/yab2xw), a selector is passed in, which the method will try to use in a number of ways before deciding that there's no matching version to return. the final test looks like this:
try: date = DateTime(selector) except: raise VersionControlError( 'Invalid version selector: %s' % selector ) else: ... RETRIEVE BY TIMESTAMP HERE
I don't know the ZVC internals but relying in such a thing doesn't seems to be the Right Thing™, I may be wrong, though ;-) -- ___________________________________________________________________ Dorneles Treméa · Developer · Plone Solutions · Brazil Consulting · Training · Development · http://plonesolutions.com ___________________________________________________________________ Plone Foundation · http://plone.org/foundation · Protecting Plone
participants (3)
-
Dorneles Treméa -
Jens Vagelpohl -
Rob Miller