Changed Traversable to call the original __bobo_traverse__ method before 
attempting to use attribute access to find the desired object.  This ensures 
that the monkeypatched object retains the same behavior as the original 
object during traversal.  Also, added checks to see if the request is a 
WebDAV request in which case attribute lookup is performed without 
acquisition (see BaseRequest.traverse for why this is important).

        MountedObject.SimpleTrailblazer._construct()

        removed in former Zope versions from the AccessControl Python
        implementation)

ZPublisher.BaseRequest: The publisher would happily publish attributes
of type 'bool' and 'complex'.

      - Collector #1991: ZPublisher did not deal properly with a trailing
        %20 in the URL

'zopectl work' properly

      - zope.app.introspector was included with the source archive

This is the code used to build the Zope 2.9.0 Windows installer.

It bundles Python 2.4.2, lives in peace with zpkgtools, moves
to InnoSetup 5, and simplifies most parts of the build-the-
installer process.

o Some of the error messages did not close '<p>' tags.

stick the path and "/cc" in the same quoted string.  Unsure why that
change was made (it worked fine before -- and now).

      - Collector #2002: fixed broken 'ls -R' functionality (didn't
        recurse properly subclasses of OFS.Folder)

- Wrong branch

      - Collector #2002: fixed broken 'ls -R' functionality (didn't
        recurse properly subclasses of OFS.Folder)

- I must be blind

- Another dependency

- Fetch the dependencies with curl

  Remove module that doesn't work and isn't being used.

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.

InnoSetup 4 CAN NO LONGER BE USED.

Besides that there's no future in relying on obsolete
versions of tools, version 5 introduced a vastly easier
way to manage the custom dialog pages Zope wants.  That
allowed getting rid of about 60 lines of inscrutable
Pascal code.  Of course the code that replaces them is also
inscrutable, but there's about 60 fewer lines of it to
torture future generations ;-).

This matches the set of files converted by the Z4I
Windows installer now, except omits .csv files (because
there aren't any of those in the Zope tree).

The build-the-Windows-installer dance used to use it.

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.

Don't know why it was hidden before, but can't think of a
reason, and the lack of makefile output showing its creation
just confused the heck out of me for 10 minutes ;-).

The functional tests don't even try to run, but at least this
exercises 6724 of the unit tests.

Someone who understands how Zope3 testing was changed to work
from a zpkgtools-based install should be able to figure out
how to improve this.

the password, and to stick on this screen until the passwords match.
I wrote this for a now-old Zope Z4I Windows installer, but there's
surely no reason to keep it secret ;-).

Also fiddled all the Pascal code to give it uniform indentation.

The build-the-installer process now completes, and running
the installer creates something that may or may not be a
working Zope.  It starts fine as a Windows Service, and at
least "looks like a Zope" ;-)

Nothing in the build-the-Windows-installer process here
uses anything in the root of the inst/ directory anymore.
Instead the WinBuilders zope.mk builds Zope all by itself,
using the Python created by python.mk.  Everything these
used to use in the root of the inst/ directory was so out
of whack with current reality that there was no point even
trying to reverse-engineer what it thought it was doing.

Note that comments in the code highlight what look like
bugs in distutils, and in the Windows xcopy command (that
last one took hours to track down -- sheesh).

        (RNFR now returns 350 as status code instead 250)