Log message for revision 71221:
  Step 2: Make aq_acquire aware of __parent__ pointers, even if the object
  isn't acquisition wrapped.

Log message for revision 71223:
  Add another test that tests acquisition wrappers with containers that have __parent__.

Log message for revision 71225:
  Cosmetics: adjust a piece of code that I added earlier to the indentation
  style of the overall file

Log message for revision 71226:
  Cleanup:
  * no need to introduce another variable where we check for a __parent__ attribute
  * clean up after failed getattr (it throws an AttributeError)
  * properly DECREF the __parent__ attribute when it's no longer needed and
    the wrapper that is temporarily created from the __parent__ attribute.

Log message for revision 75578:
  Added a test to Acquisition that shows the current segmentation fault problem, when Acquisition goes in circles.

Log message for revision 76140:
  First attempt to fix 'Acquisition problem' when encountering cyclic hierarchies via __parent__ pointers. [hannosch, nouri]


In addition, Hanno and Nouri's fix was expanded to not only cover circular __parent__
pointers but also to cover a mixture of circular __parent__ and aq_parent pointers
(which can occur when old Implicit acquisition meets new __parent__ pointer code).

Also cleaned up much of the comments and added more comments.

  Allow assignment to a wrapper's __parent__.

  Warming up: Make acquisition wrappers have __parent__ in addition to aq_parent
  (they point to the same thing).

work done for Infrae.

The REQUEST should not accept holds after it has been closed.

o See http://www.zope.org/Collectors/Zope/2333

registered via five:registerPackage.

        errors

      - Collector #2295: Comments in PythonScripts could lead to syntax
        errors

        errors

      - DAV: compatibility with Windows Web Folders restored by adding
        a configuration variable that controls the sending of the
        non-standard MS-Author-Via and Public headers. Thanks for
        PatrickD for the the hard work coming up with an initial
        patch.
        (http://zope.org/Collectors/Zope/1441)

Revert code that fixed litmus cond_put_corrupt_token and fail_cond_put_unlock tests, because the fix broke (the more important) lock_collection test.

Add a description of the current litmus failures in webdav/litmus-results.txt.

Add support for delayed initialization of packages through a _packages_to_initialize list on the Products package

Delay registration of python packages until a moment when a ZODB connection is available http://www.zope.org/Collectors/Zope/2293

        webdav.Resource.dav__simpleifhandler.  If the resource is not
        locked, and a DAV request contains an If header, no token can
        possibly match and we must return a 412 Precondition Failed
        instead of 204 No Content.

        in webdav.Resource.dav__simpleifhandler.  If the resource is
        locked at all, and a DAV request contains an If header, and
        none of the lock tokens present in the header match a lock on
        the resource, we need to return a 423 Locked instead of 204 No
        Content.

        because we returned "412 Precondition Failed" instead of "423
        Locked" when the resource attempting to be moved was itself
        locked.  Fixed by changing Resource.Resource.MOVE to raise the
        correct error.

the wrong thing.

propwformed were failing because Zope did not strip off the
xmlns: attribute attached to XML property values.  We now strip
off all attributes that look like xmlns declarations.

resource hasn't been locked with, we should return an error
instead of a 20X response.  See
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html
for rationale.

Prior to Zope 2.11, we returned a 204 under this circumstance.
We choose do what mod_dav does, which is return a '400 Bad
Request' error.

This was caught by litmus locks.notowner_lock test #10.

of litmus version 10.5 (http://www.webdav.org/neon/litmus/)
expose a bug in Zope propertysheet access via DAV.  If a
proppatch command sets a property with a null xmlns,
e.g. with a PROPPATCH body like:

<?xml version="1.0" encoding="utf-8" ?>
<propertyupdate xmlns="DAV:">
<set>
<prop>
 <nonamespace xmlns="">randomvalue</nonamespace>
</prop>
</set>
</propertyupdate>

When we set properties in the null namespace, Zope turns
around and creates (or finds) a propertysheet with the
xml_namespace of None and sets the value on it.  The
response to a subsequent PROPFIND for the resource will fail
because the XML generated by dav__propstat included a bogus
namespace declaration (xmlns="None").

Fixed by amending OFS.PropertySheets.dav__propstat.