[ZODB-Dev] ZODB 3.2.8 final released

[Tim Peters]

[Tim Peters]
>> Neither did I, Paul -- I don't know ZopeUndo from a hole in the ground.
>> It _might_ have helped if you had added an entry to ZODB's news file
>> recording that ZopeUndo.Prefix had changed.
>> ...

[Paul Winkler]
> Yeah, but I don't know ZODB's news file from shinola ;-) I've never
> checked out ZODB; ZopeUndo appears in lib/python/ in a Zope sandbox, and
> I updated CHANGES.txt which was all I thought was needed.
> ...
> but again, I've never worked on ZODB proper and don't know the policies
> for documenting changes to it.

That's OK.  A Zope checkout contains about a dozen directories full of code
that doesn't really "belong" to Zope.  When you move to Zope 2.8, it will be
much more obvious, because most of the "foreign" directories are very
visibly fetched from other projects:

$ svn up

Fetching external item into 'lib\python\zope'
External at revision 30212.

Fetching external item into 'lib\python\BTrees'
External at revision 30212.

Fetching external item into 'lib\python\Persistence'
External at revision 30212.

Fetching external item into 'lib\python\persistent'
External at revision 30212.

...

> Funny thing is, I've been running a Zope-2.7.6-b2 client against a
> Zope-2.7.3 ZEO server since Monday and hadn't noticed any problems yet
> ... I guess I hadn't tried to undo anything. Just now I checked and
> apparently manage_undoForm always says "there are no transactions that
> can be undone." I presume that's the problem you guys found.

Tres did the opposite, running a ZODB 3.2.7 (new) ZEO server with an older
ZEO client.  I can't tell you exactly what he did to provoke disconnections,
so I cc'ed him on this.  Looked like he was just clicking around on the ZMI.

[and later]
> no, I'm wrong. With that client/server combination, undo works ok in the
> zope root, but elsewhere gives AttributeError, "Prefix instance has no
> attribute 'value'".

Right, the newer client no longer created the .value attribute the older
server was looking for.  In Tres's direction, the older client didn't create
the .path attribute the newer server was looking for.

> anyway, enough flogging a dead horse. thanks for taking care of this.

Hey, that's part of the job here <wink>.  I added a new test to verify that
the union of old+new attributes exists in 3.2.8, but didn't actually test
your new client + old server combo by bringing up one of each; Tres did test
"his" combo with a preliminary patch.  You might want to try that (by
temporarily installing ZODB 3.2.8 on a client) to verify that your scenario
does in fact work for you now.