- Collector #1899: fixed migration issue when using export/import for
        ZCatalog instances

packages than single pieces

  with Python
- remove use of the long-deprecated xmllib module, again using the Expat
  that comes with Python as a replacement

use it

In the interest of keeping myself sane, I've left the "Trunk only
(unreleased)" section alone

and not just when the file is missing. This is a forward port from Zope-2_7-branch.

        ZTUtils.make_query()

      - ZCatalog: refreshCatalog() could not be called safely from a ZEO
        client script

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

use the pushStream/popStream model from the Zope 3 codebase instead of the
interpretWithStream model.  The two are entirely equivalent in context,
but I think the push/pop model offers more flexibility in the long run

rather then runzope to avoid all the hassle with
not detaching and thus mysteriously stopping zopes.

implementations of the TAL interpreter

Collector 1860:  use an optimistic savepoint in CopySupport._getCopy
(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.

- 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

        security reasons

Worm around suspected Windows socket bug in Windows trigger code.

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()