Eric Roller's Development Blog

Seen errors like this, e.g. upon "svn update" issued on a remote machine when the repository is on a server:

svn: Berkeley DB error for filesystem '.../Repositories/proj/db' while
opening 'nodes' table: Invalid argument
svn: bdb: file nodes (meta pgno = 0) has LSN [95][515282].
svn: bdb: end of log is [95][14597]
svn: bdb: .../Repositories/proj/db/nodes: unexpected file type or

Not sure what the main cause is, but it could be a bug with svnserve since it is the one who is running as root. Login with ssh on the server and cd to the directory mentioned in the error:

cd Repositories/proj/db
ls -l
-rw-r--r--   1 root  goblin   1048576 Aug  4 17:42 log.0000000095
-rw-r--r--   1 root  goblin   1048576 Aug  4 17:52 log.0000000096

Notice that there are files whose owner is root while the other files (not shown) are owned by globlin. We can fix that with chmod:

sudo chown goblin log.000000009*
cd ../..
svnadmin recover proj

Back on the remote machine, try again to run "svn update".

The goal is to access the preferences of a second application and to be able to change those preferences. I thus tried:

theDef = [[NSUserDefaults standardUserDefaults] retain];
[theDef addSuiteNamed:MyHelperAppDomain];

However, when a setting was changed and when I instruct the NSUserDefaults class to synchronize, the changes are not saved in the MyHelperAppDomain. This is because addSuiteNamed: only adds the settings from that domain; it does not change the domain!

How did I find the mistake? Tried this command in the Terminal:

> defaults find DateFormat
Found 1 keys in domain 'se.tredje.myapp': {DateFormat = "%+"; }
Found 1 keys in domain 'MyHelperApp': {DateFormat = "%F"; }

To change the preferences for a different application domain, I have found this alternative:

CFPreferencesSetAppValue( (CFStringRef) DefaultDateFormat,
    (CFStringRef) DefaultDateFormatDefault,
    (CFStringRef) MyHelperAppDomain );
CFPreferencesAppSynchronize( (CFStringRef) MyHelperAppDomain );

Saw this before version 2.2.2 and the solution was to use the current beta version of Apache (2.1.8-beta I think). Now I see it again for the new photo page.

Found some online forum message where they suggested to change the output_buffering value in /usr/local/lib/php.ini to something like "1048576" (1MB). I don't have pictures that large so I set it to "512000" (500kB). This solved the problem for me.