Othere tests don't pass though, maybe I think due to __implemented__ and
__provides__ attributes in the persistentclass state.

  Make instances have a lib/python directory with a proper README.txt by default.
  Note that it's already automatically put on the PYTHONPATH by Zope, it just
  wasn't there yet by default.

Note that it's already automatically put on the PYTHONPATH by Zope, it just
wasn't there yet by default.

startup, we still want to put it in the dbtab multidatabases dict.

This happens when unit tests call Zope2.startup(), because Testing has a
specific custom_zodb.py loaded at startup that uses a DemoStorage.

        (RNFR now returns 350 as status code instead 250)

        (RNFR now returns 350 as status code instead 250)

See http://mail.zope.org/pipermail/zodb-dev/2005-December/009662.html
for a fuller problem description.
Unit test included.

r21753 | efge | 2006-01-06 18:58:06 +0100 (Fri, 06 Jan 2006)
Fix cleanup of five:traversable.

r21752 | regebro | 2006-01-06 18:51:19 +0100 (Fri, 06 Jan 2006)
If one class was set to have a localsite hook twice, removing the hook
would be attempted twice during the cleanup of unit tests, and the tests
would fail.

      - Collector #1939: When running as a service, Zope could
        potentially collect too much log output filling the NT Event
        Log. When that happened, a 'print' during exception handling
        would cause an IOError in the restart code causing the service
        not to restart automatically.

        Problem is that a service/pythonw.exe process *always* has an
        invalid sys.stdout.  But due to the magic of buffering, small
        print statements would not fail - but once the file actually
        got written to, the error happened.  Never a problem when
        debugging, as the process has a console, and hence a valid
        stdout.

- Update with Mark's comments:

        Problem is that a service/pythonw.exe process *always* has an
        invalid sys.stdout.  But due to the magic of buffering, small
        print statements would not fail - but once the file actually
        got written to, the error happened.  Never a problem when
        debugging, as the process has a console, and hence a valid
        stdout.

      - Collector #1939: When running as a service, Zope could
        potentially collect too much log output filling the NT Event
        Log. When that happened, a 'print' during exception handling
        would cause an IOError because the service had no 'redirection
        pipe' anymore (because it's shutting down) to write to,
        causing the service to not restart automatically.

and http://mail.zope.org/pipermail/zope-dev/2005-December/026236.html from the Five
repository:

Log message for r21321:
  Explain what this test does and fix misleading and risky usage of pprint

Log message for r21322:
  Fix this test and re-enable it

Log message for r21325:
  Add changes entry for some recently fixed bug
  update Five 1.2 changes history
  bump version number after 1.3c "release"

the 'charset' field is automatically if not specified by the
application. The 'charset' is determined by the content-type header
specified by the application (if available) or from the
zpublisher_default_encoding value as configured in etc/zope.conf

level at which conflict errors (which are normally retried
automatically) are logged. The default is 'info'.

This doesn't interfere with the error_log site object which copies
non-retried conflict errors the the error log at level 'error'.