Graham Dumpleton's questions

We are having to migrate a web server hosting a subversion repository via mod_dav_svn to a new machine and host name. To ease transition, we are looking at running the two web servers in parallel with repository NFS mounted on both at the same time. We can then progressively do a 'svn switch' on checked out working copies to new host name.

The concern is that each mod_dav_svn is a different version. The older is 1.3 and the newer is 1.6. Further, the actual repository (db/format) is '1', so potentially wasn't ever upgraded when we went to 1.3.

The release notes for 1.5 and 1.6 both say words to the effect:

Repository Upgrades - The Subversion 1.6 server works with 1.5 and older repositories, and it will not upgrade such repositories to 1.6 unless specifically requested to via the svnadmin upgrade command. This means that some of the new 1.6 features will not become available simply by upgrading your server: you will also have to upgrade your repositories. (We decided not to auto-upgrade repositories because we didn't want 1.6 to silently make repositories unusable by 1.5 — that step should be a conscious decision on the part of the repository admin.)

Also, since the repository format is still '1' even though using 1.3, then likely that the same applied to 1.3 as well.

So it doesn't look like there is any risk of 1.6 upgrading the repository and making it unusable to 1.3 at the same time. This will allow us to do our migrations and when we are done and old server shutdown, then we can do the 'svnadmin upgrade' on the repository to get it up to 1.6 and get access to any new features provided clients also 1.6.

Can anyone see any issues with this plan?

As per issue for MythTV backend at:

http://svn.mythtv.org/trac/ticket/7582

when running MythTV backend on MacOS X 10.6.2, it crashes with:

BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors

This message appears to come from Grand Central Dispatch.

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Crashed Thread:  1  Dispatch queue: com.apple.libdispatch-manager

Application Specific Information:
BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors

Thread 1 Crashed:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib                   0x9481ea51 _dispatch_mgr_invoke + 804
1   libSystem.B.dylib                   0x9481dcc3 _dispatch_queue_invoke + 163
2   libSystem.B.dylib                   0x9481da68 _dispatch_worker_thread2 + 234
3   libSystem.B.dylib                   0x9481d4f1 _pthread_wqthread + 390
4   libSystem.B.dylib                   0x9481d336 start_wqthread + 30

Since the code in MythTV for this is quite early in main(), can only imagine that linking in of Grand Central Dispatch libraries is automatically causing some background thread to run which monitors some special file descriptor. Problem is that MythTV backend is closing all file descriptors from 3 upwards and presumably is closing this special file descriptor as well.

The question is, is there any way to setup MacOS X to say not to use Grand Central Dispatch and use what ever was used under MacOS X 10.5 to try and avoid this issue until MythTV people can be bothered looking at it and making changes to code.

Separately, can anyone explain whether Grand Central Dispatch is using some special file descriptor as I reason.