work properly with a top-level user folder with enabled password
        encryption.

  client script

        problems for some .zexp files e.g. Squishdot instances)

No commit message

(there's no possiblity of rollback here, so no need to insist that the
data manager support rollbacks).

The other part of this change is in ZODB 3.4.1b4, also stitched in
by this checkin.

- added z3 -> z2 interface bridge

Avoids exiting the zopectl shell, if run from there.

- made sure custom strings like MessageID are not converted by ustr
- synced TALInterpreter code and tests with zope.tal where possible without changing behavior
- backported MessageID support from zope.tal

See the thread starting at
 http://mail.zope.org/pipermail/zope/2005-July/160433.html
for gory details.

Note that Zope trunk and 2.8 also have a third copy of this
code, in

    lib/python/zope/server/trigger.py

That's "a Zope3 problem".

      - Collector #1807: fixed memory leak in cAccessControl.guarded_getattr()

Additional test. CMF requires this behaviour.

Display offending line when warning about getOwner(1) deprecation.

Will stitch in again via svn:externals.

(http://www.zope.org/Collectors/Zope/1813).

o CMFCore will include it after 1.5, with an appropriate module alias for
  backward compatibility.

This also includes a patch to HTTPRequest which is implemented
directly in Zope 2 rather than the monkey Five does.

- ported and reversed bridging code from Five

  >>> fromZ3Interface(x) is fromZ3Interface(x)
  True

 collector 1828 which was already marked as resolved.

Tim pointed out that loadEx is supposed to return a 3-tuple.  This is related to collector 1828 which was already marked as resolved.

- removed all Five dependencies introduced in r30996
  (this fixes the infinite loop issue, but adds redundant interface definitions because we can't use Five's bridging code)

(this fixes the infinite loop issue, but adds redundant interface definitions because we can't use Five's bridging code)