Merging Stackless Python 3.0.1

Part of the Stackless Python release backlog.

Preparation

1. Updating Tortoise SVN.
   • I would have skipped this step, but the web site claims that bugs have been fixed with Tortoise Merge.
   • Unfortunately, I should have still skipped this step, as what I forgot was that I use Perforce Merge which can be freely obtained and used for merging with Tortoise SVN.
   • A reboot was required to finish the installation.
2. Updating my local Stackless SVN repositories (release30-maint).
   • I might have last worked on it at work, or Kristjan Valur might have checked in fixes or merges in the meantime. Check-in emails are sent to the Stackless-checkins mailing list which I subscribe to, so I know no merging has taken place but that there have been fixes which I may not have. It is a quick process, so it is no big deal to do it just in case.
3. Updating my local Python SVN repository (release30-maint).
   • I am not 100% sure about the release process for Python 3.0.1 but I suspect that the development is done within the py3k branch, with selective merging made into release30-maint, where releases are then made from. All I really need to do is get the latest of the 3.0 release branch, then merge from that into the corresponding Stackless branch.
4. Ascertaining the release revision.
   • Looking at the checkin comment for the revision of the Python SVN r301 tag, it says Copied from python/branches/release30-maint, r69557.
   • This means I need to merge up to that revision in the Python release30-maint branch, into the Stackless release30-maint branch.
5. Ascertaining the merge revision range.
   • I need to know the highest revision of the Python release30-maint branch which has been merged into the Stackless release30-maint branch.
   • Looking at the history of the Stackless release30-maint branch, the last relevant comment by me is This brings release30-maint to the release tag level. Not very helpful. This means I need to look at the Python r30 tag, which has a comment of Copied from python/branches/release30-maint, r67505.
   • This gives a merge revision range of r67505 to r69557.

Merging

1. Right click on the Stackless release30-maint directory and select Merge from the Tortoise SVN context sub-menu.
2. Selected "Merge a range of revisions" and clicked the Next button.
3. Ensured that svn+ssh://pythondev@svn.python.org/python/branches/release30-maint was selected in the "URL to merge from" box.
4. Entered 67505-69557 in the "Revision range to merge" box and clicked the Next button.
5. Scratched my head at the "Merge Options" page and just clicked on the Test merge button.
6. There were 22 conflicts and various other things which were problematic, after the gigabyte of traffic it took. I decided to just do a merge, in order to not waste any more bandwidth.
7. All of the conflicts have been in files which Stackless does not modify. The documentation restructured text files for instance. Not sure what is going on there, maybe I determined the wrong merge range. There is certainly a lot of merging going on. Oh well, another gigabyte gone.
8. Skipped missing target: D:\SVN\_python\stackless-branches\release30-maint\Tools\msi\crtlicense.txt. This is not a very helpful message. If I had to guess, it would be another hint at this being a misconfigured merge. Manually copied the file over, as you do.
9. I am going to do a preliminary build with the unreliable Visual Studio 2008, in order to determine whether the merge resulted in anything usable. It should compile fine, but compilation correctness problems will show up when the unit tests are run.
10. Created a new non-version controlled release30-maint-export directory beside the version controlled SVN release30-maint one. Right clicked on release30-maint and selected "Export" from the Tortoise SVN context menu. Exported a copy of the versioned files from release30-maint into the new release30-maint-export directory.
11. Compiled release30-maint-export with Visual Studio 2008. I am not compiling the dependencies, but it will compile the basics of the interpreter and the DLLs, which I can use to run the unit tests.
12. The compilation was successful with only the dependencies erroring. Normally, I have to fight with Visual Studio, to get the correct version of it to open a solution file. Then things like the socket module fail to compile, indicating something is different with my environment than the one others use. This was the easiest compilation I have had in a long time. Fixes must have made it into this release, which addressed my past compilation problems.
13. Time to run the Stackless unit tests. I am running these first as they take no time at all compared to the Python unit tests.
14. Unfortunately the Stackless unit tests crashed. I am running the debug version of Python, so it might be an assertion. Will run the Python unit tests and see how they respond, before checking that out.
15. Python unit test failure 1:

    test test_descr failed -- Traceback (most recent call last):
      File "D:\SVN\_python\stackless-branches\release30-maint-export\release30-maint
      \lib\test\test_descr.py", line 3891, in test_method_wrapper
        self.assertEqual(l.__add__, l.__add__)
    AssertionError:  != 
    <method-wrapper '__add__' of list object at 0x05054D38>

    It is possible that this is caused by the incorrect compilation results of my Visual Studio 2008 installation.
16. Python unit test failure 2:

    ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\SVN\_python\stackless-branches\release30-maint-export\release30-maint
      \lib\distutils\tests\test_build_ext.py", line 22, in setUp
        os.mkdir(self.tmp_dir)
    WindowsError: [Error 183] Cannot create a file when that file already exists:
    'D:\\SVN\\_python\\stackless-branches\\release30-maint-export\\release30-maint
    \\lib\\distutils\\tests\\xx'

    This does not look like a compilation problem, more likely a problem with the unit test itself. Or something to do with my Windows Vista operating system installation.
17. Revisiting the Stackless unit test crash and attaching to the running Visual Studio instance I used to compile, the crash happens in the garbage collection when some object is being removed from a list in a dictionary which a frame being deallocated has the last reference to.

So, there are potentially two bugs to fix. I need to compile this source code at work tomorrow, in order to see what the correctly compiling Visual Studio compiler does. But for now, I can consider this merge a success, and can check in the result to the python.org SVN repository.

EDIT: Work compilation results.

I compiled the checked in source code at work, with the install of Visual Studio 2008 there. Strangely, it gives the same results as my home install. The same crash and unit test failures.