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.

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)

- Collector #1815: ZCTextIndex accepts (again) sequences of strings to be indexed.

      - Collector #1815: ZCTextIndex accepts (again) sequences of strings to 
        be indexed.