Daniel Schneller's Blog

Today we found the reason for our sometimes abysmal CVS performance, even though the repository is located on a fast SAN: Locks were written to the local disks rather than the SAN. For years we have been using CVS as our internal version control system. The repository has grown to about 20GB and covers 6 years of code and resources in several hundred thousand files and their history revisions. Some time ago we migrated the repository data from an internal disk subsystem to a SAN based on 15k hard drives. The server is a Dual Xeon HP box with 4GB of RAM serving about 50 users. Even though we thought we had a decently fast setup here, sometimes – especially when more than 10 or 15 people started to checkout or synchronize their Eclipse workspaces – performance would start to really degrade. In some cases working on branches only was possible after increasing the client timeouts to 3 minutes! Our datacenter administrators provided us with I/O statistics in which we recently realiz

I regularly need to send a zipped copy of a folder that is a local Subversion working copy. Every time I create the archive I end up with a file that’s larger than needed, because it contains the hidden Subversion metadata “.svn” subfolders. Here is quickly hacked together AppleScript than delegates the actual work to the Unix “find” command, but can be attached as a Folder Action. I now have folder on my Desktop called “Strip SVN Metadata” and I just Option-Drag anything from a Subversion working copy there (making a copy, not moving) and a few seconds later I can just zip it from there without the .svn folders. on adding folder items to this_folder after receiving added_items tell application "Finder" set fold_name to the name of this_folder try repeat with i from 1 to number of items in added_items set new_item to item i of added_items set the item_path to the quoted form of the POSIX path of new_item

Today I tried to map a network drive to a folder shared via SMB from Mac OS X. I enabled sharing in System Preferences and set up the user account appropriately. But whenever trying to connect from Vista, I ended up with “Systemfehler 1326” (“System error 1326 has occurred. Logon failure: unknown user name or bad password”) complaining about invalid username or password. First I suspected a problem with my longish password that contains special characters, but that was not it. Turns out it is a compatibility problem/feature between the Samba configuration in OS X (the component responsible for sharing folders via the SMB protocol) and Vista’s default security settings. First a solution for the impatient: On Vista launch regedit.exe and navigate to “HKLM/SYSTEM/CurrentControlSet/Control/Lsa”. Check the value of “LmCompatibilityLevel” and set it to 1 – it defaults to 3. For a list of settings for this key, see Microsoft Knowledge Base Entry 239869 On my system I did not have to