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

      - Collector #1852: fixed wrong URL construction in webdav.davcmds

Refinement of collector issue 1837 - add next() and xreadlines() for a full file interface to ZPublisher/HTTPRequest.py and appropriate test case + changes.txt entry

Deleted this directory, which is actually part of ZODB.
Will stitch in again via svn:externals.

- added some implements() declarations

------------------------------------------------------------------------
r33281 | philikon | 2005-07-12 18:03:36 +0200 (Tue, 12 Jul 2005) | 4 lines

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

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.