Release testing and the relationship between 'bzr selftest' and plugins

[Vincent Ladeuil]

>>>>> Gordon Tyler <gordon at doxxx.net> writes:

    > Regarding running `bzr selftest` as part of the installer building process,
    > I started `time ./bzr selftest --parallel=fork --no-plugins` this morning
    > on the Macbook I use to build the OS X installers so I can see how long it
    > would take. Building the installer itself already takes about 30 minutes
    > for a completely clean build, although I can usually do an incremental
    > build for minor plugin version changes. The primary culprit is compiling
    > pyqt.

    > My suspicion is that it's going to take a very long time. The Macbook is
    > kinda dinky in comparison to my Windows desktop machine and the desktop
    > took a very long time to run the full suite.

Tests are slower on windows to start with (unless this has changed
recently).

On OSX, using a ram disk is a serious boost especially on laptops where
hard disks are often of the 5400rpm specie.

I think I had a recipe for that, let me dig...

#!/bin/sh
# Size in MB
SIZE=${1:-512}
SIZE_IN_BYTES=`expr ${SIZE} \* 2048`
# Path
RAMDISK=${2:-ramdisk}
if [ ! -e "/Volumes/${RAMDISK}" ] ; then
    RAW_DEV=`hdiutil attach -nomount ram://${SIZE_IN_BYTES}`
    diskutil erasevolume HFS+ "${RAMDISK}" ${RAW_DEV}
fi
# to get rid of the ramdisk:
# hdiutil detach ${RAW_DEV} 

Then 'TMP=/Volumes/${RAMDISK} bzr selfest' should do.

Now, of course, --parallel=fork in itself consume memory so you have to
find a balance to avoid swapping :)

     Vincent

P.S.: Re-reading the script makes me wonder why 2048 is used
      here... instead of the usual 1024 ;)