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

  Merge a couple of fixes that are related to http://www.zope.org/Collectors/Zope/1947
  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"

(Reverted r40251 as I quite obviously didn't know what I was doing.)

    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

Added a 'conflict-error-log-level' directive to zope.conf, to set the
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.

(Keeping the general instructions to let ./configure choose
the right version of python for you.)

  Several zope.app packages were forgotten to be included in the
  first beta due to the now zpkg-based build and release process.

No commit message

Log message for revision 40576:
  No longer use the defaultLayer directive.  It didn't do anything anyway.

Log message for revision 40587:
  Update Five to 1.3c.

Log message for revision 40588:
  Fred fix a speling error in Zope 3.2.

Log message for revision 40590:
  sync with five repo

Log message for revision 40592:
  Zope 2's version.txt will from now on reside on the Zope2 package.
  The reason for that is because zpkg and distutils can't deal with arbitrary
  data files that don't belong to a certain package.

process actually still works.

ObjectManager now has an hasObject method to test presence. This
brings it in line with BTreeFolder.

ObjectManager now has an hasObject method to test presence. This
brings it in line with BTreeFolder.

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

Improved logging of ConflictErrors. Now a log is made at level BLATHER
with traceback for any conflict retried. In addition, a log is made at
level ERROR for a conflict that can't be retried anymore and is returned
to the browser as an error. Nothing is logged anymore at level INFO.