“please get a newer Subversion client”

An old problem -- a new trick...

This error message is familiar to any Subversion user. The error is the result of trying to access a new working copy (WC) with an old subversion client.

An example scenario:

• Your Subversion WC is shared between several hosts.
• You work on the WC from one host (e.g: Centos5).
• You access the WC by mistake from another (e.g: Fedora11).
• The next time you try accessing your WC from the old host, you get this error message.

This behavior is pretty dumb:

• Subversion silently upgrade your WC metadata.
• It doesn't bother asking your permission to do so.
• It does it even for supposedly non-modifying actions like 'svn status'.
• The official FAQ says your only recourse is to upgrade the client...
• And you may "loose" many uncommitted changes!
  

Previously, I didn't have any better idea than this:

• Check out a clean working copy to a temporary directory.
• Use: diff -ru -x .svn damaged-wc/ fresh-wc/
• Manually merge files from damaged-wc/ to fresh-wc/
• Keep working from fresh-wc/
• Remove damaged-wc/

I just found a very nice workaround that was briefly mentioned:

rsync -r --progress \
--include='*/' --include '.svn/**' --exclude '*' \
fresh-wc/ damaged-wc/

That post only mentioned that emsearcy from OSUOSL is the source of this nice trick -- after googling I found it in an IRC log (big one).

So, this should serve as another documentation for this.

USB mouse + hibernation

My laptop (smolt) works nicely, but I have one quirk -- whenever the laptop wakes up from hibernation (suspend to disk), the external USB mouse does not function at all (while the synaptics touchpad works flawlessly).

My workaround was always to plug it after the wakeup (or if it was plugged before, simply take it out and re-plug it). Few weeks ago I stumbled on a nicer workaround:

1. Run lsusb (the mouse doesn't show, but...)
   
2. It works
3. Running lsusb again, for verification, shows the mouse.

It seems like the bug is in the host controller driver, or is it?
Can somebody shed more light about the real bug?

monitoring fetchmail

I use fetchmail to pull mail from several accounts in several places.
After my ISP had some "technical difficulties" it was obvious I should monitor
the logs for fetchmail errors.

Surprisingly enough, I didn't find anything ready for logwatch. So now there is ;-)

Also opened a bug report with links to the script + config file and their installation
directories.

Enjoy,