The changes were mostly in the Persistent module. Here, the changes were minimal:

- Introduce zodbpickle for PyPy and Python 2.7 to fix noload.

- Centralize the construction of Picklers/Unpicklers to account for the differences between Python2/3/zodbpickle.

- A few extra gc.collect() calls.

- Some minor printing differences in the doctests due to the Python implementation of BTrees.

Checkpoint on ZODB under PyPy: 25 failures, 25 errors (needs my persistent fork). Many of them are printing differences, some have to do with the Python persistent implementation, especially PickleCache

Use zodbpickle under pypy and 2.7 for a working noload. Also add pypy to tox so I can start testing it.

Fix manifest and setup

- include .coveragerc
- Add author, author_email, keywords

    $ check-manifest
    lists of files in version control and sdist match
    $ pyroma .
    ------------------------------
    Checking .
    Found ZODB
    ------------------------------
    Final rating: 10/10
    Your cheese is so fresh most people think it's a cream: Mascarpone
    ------------------------------

Add tests for repozo's parseargs().

Fixes https://github.com/zopefoundation/ZODB/issues/28

It didn't work for me, because nose would crawl inside manual_tests, try
to run test_fstest.py, and fail (because that test is manual and
requires extra setup, like putting fstest.py on PYTHONPATH).

I also don't think that we want to exclude test layers from coverage
measurements (nose doesn't support them).

This change makes 'tox -e coverage' use zope.testrunner like it does for
regular tests.

See https://github.com/zopefoundation/zope.testrunner/pull/19

Cleaned up exception logging and changed pins

- Always use logger.exception rather than logging.error when logging
  exceptions ar the error level.

- Fixed an incorrect call to logging.exceotion (like PR #26, but better :).

- Removed dependency pins and added one to overcome some breakage in
  zope.testrunner.

None of this seems to be CHANGES worthy.

Conflicts:
	CHANGES.rst
	setup.py

We have been registering our custom level names ("BLATHER", "TRACE) in the
wrong order since 2004.  Before Python 3.4, the stdlib ``logging`` module
masked the error by registering them in *both* directions.

'width=1' causes excess wrapping.

See: http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/

Downloaded from http://downloads.buildout.org/2/bootstrap.py

Small fixups while learning ZODB

As noted in recent commit, verbose option handling in fsrefs.py was
broken. On review Tres suggested to make VERBOSE a local variable as
currently it is used only in one function main().

Suggested-by: Tres Seaver

Currently that script does not run because of import error:

    $ python src/ZODB/scripts/netspace.py
    Traceback (most recent call last):
      File "src/ZODB/scripts/netspace.py", line 13, in <module>
        from ZODB.referencesf import referencesf
    ImportError: No module named referencesf

and that ZODB.referencesf module was moved to ZODB.serialize long ago in

    ec014812    (Move referencesf to ZODB.serialize.)
    ae7e113e    (Ack!  Deleted the wrong file in the last checkin.)
    355ff4ac    (One more try.  Commit the version with referencesf.)

only the conversion missed the netspace.py script.

Fix it.

provide more information when logging setstate failures

For this script verbose mode was added in 57bca1f0 (Add -v option to
control whether tracebacks are printed.) and was later broken in
6dd809d2 (Converted to a buildout and converted externals to
dependencies.) - the change forgot to add global specifier for VERBOSE
variable while moving its assignment into function context.

As a result currently we have

    $ python ./src/ZODB/scripts/fsrefs.py -v data.fs
    Traceback (most recent call last):
      File "./src/ZODB/scripts/fsrefs.py", line 155, in <module>
        main()
      File "./src/ZODB/scripts/fsrefs.py", line 104, in main
        VERBOSE += 1
    UnboundLocalError: local variable 'VERBOSE' referenced before assignment

Fix it.

Fix for #16

Thanks!

see https://github.com/zopefoundation/ZODB/issues/16

see https://github.com/zopefoundation/ZODB/issues/16