1. 21 Jan, 2006 2 commits
    • Sidnei da Silva's avatar
      · d9a7a8ad
      Sidnei da Silva authored
      - Wrong branch
      d9a7a8ad
    • Sidnei da Silva's avatar
      · aa16e459
      Sidnei da Silva authored
            - Collector #2002: fixed broken 'ls -R' functionality (didn't
              recurse properly subclasses of OFS.Folder)
      aa16e459
  2. 19 Jan, 2006 3 commits
    • Sidnei da Silva's avatar
      · 3fda7df6
      Sidnei da Silva authored
      - I must be blind
      3fda7df6
    • Sidnei da Silva's avatar
      · 5beadefb
      Sidnei da Silva authored
      - Another dependency
      5beadefb
    • Sidnei da Silva's avatar
      · 9c4ce6f0
      Sidnei da Silva authored
      - Fetch the dependencies with curl
      9c4ce6f0
  3. 15 Jan, 2006 1 commit
    • Tim Peters's avatar
      Move to InnoSetup 5. · 741531a4
      Tim Peters authored
      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 ;-).
      741531a4
  4. 14 Jan, 2006 2 commits
  5. 13 Jan, 2006 5 commits
  6. 12 Jan, 2006 1 commit
    • Tim Peters's avatar
      Pain, pain, and more pain. · fbeb4f9c
      Tim Peters authored
      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).
      fbeb4f9c
  7. 11 Jan, 2006 13 commits
  8. 07 Jan, 2006 4 commits
  9. 06 Jan, 2006 1 commit
    • Florent Guillaume's avatar
      Sync with Five 1.3 r21753: · 759b71a3
      Florent Guillaume authored
      r21753 | efge | 2006-01-06 18:58:06 +0100 (Fri, 06 Jan 2006)
      Fix cleanup of five:traversable.
      
      r21752 | regebro | 2006-01-06 18:51:19 +0100 (Fri, 06 Jan 2006)
      If one class was set to have a localsite hook twice, removing the hook
      would be attempted twice during the cleanup of unit tests, and the tests
      would fail.
      759b71a3
  10. 05 Jan, 2006 1 commit
  11. 24 Dec, 2005 1 commit
  12. 23 Dec, 2005 1 commit
  13. 22 Dec, 2005 1 commit
  14. 21 Dec, 2005 4 commits
    • Stefan H. Holek's avatar
      3157f832
    • Andreas Jung's avatar
      more tests and fixes · 7596da86
      Andreas Jung authored
      7596da86
    • Sidnei da Silva's avatar
      · 14923f9b
      Sidnei da Silva authored
            - 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.
      14923f9b
    • Andreas Jung's avatar
      37e2029c