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'.

(Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.)

     - Collector #1976: FTP STOR command would load the file being
       uploaded in memory. Changed to use a TemporaryFile.

import directories. (Merged from trunk.)

Thanks to Tim Peters for pointing out the flaw!

o ZODB 3.6 properly removed it, but Zope needs to keep it for another release
  because ZODB released *twice* during the Zope 2.9 release cycle.

first beta due to the now zpkg-based build and release process.

No commit message

The reason for that is because zpkg and distutils can't deal with arbitrary
data files that don't belong to a certain package.

exits.

brings it in line with BTreeFolder.

  - change SimpleItem.py to use python logging module
  - log at error when standard_error_message can't be rendered
  - give more useful info about errors rendering standard_error_message to the browser.
  - all conflict errors are counted and logged at info
  - logging makes it clear where the conflict has been resolved and where it hasn't
  - errors seen by the user are rendered with standard_error_message and are sent to the error_log which will likely copy them to the event log, depending on the users setup.
  - also checking in a functional test for generating write conflict errors.
    
  (I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges simpler)

- remove unused import.
- change SimpleItem.py to use python logging module
- log at error when standard_error_message can't be rendered
- give more useful info about errors rendering standard_error_message to the browser.
- all conflict errors are counted and logged at info
- logging makes it clear where the conflict has been resolved and where it hasn't
- errors seen by the user are rendered with standard_error_message and are sent to the error_log which will likely copy them to the event log, depending on the users setup.
- also checking in a functional test for generating write conflict errors.
  
(I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges simpler)

- all conflict errors are counted and logged at info, as they were before Florent's change
- logging makes it clear where the conflict has been resolved and where it hasn't
- errors seen by the user are rendered with standard_error_message and are sent to the error_log which will likely copy them to the event log, depending on the users setup.
- also checking in a functional test for generating write conflict errors.

(I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges simpler)

- log at error when standard_error_message can't be rendered
- give more useful info about errors rendering standard_error_message to the browser.