svn incremental backup

Just for archiving. I've got it from somewhere but i'm unable to find it. In order to create mirror repository of one already available somewhere follow these steps: $REPO = where you wan't to keep mirror (local path) $SOMEWHERE = where is your original repo

svnadmin create REPO

Add hook that will disallow of commit by anyone except svnsync fake user:

cat > REPO/hooks/pre-revprop-change

#!/bin/sh
USER="$3"
if [ "$USER" = "svnsync" ]; then exit 0; fi
echo "Only the svnsync user can change revprops" >&2
exit 1
^Z

chmod +x REPO/hooks/pre/revprop-change

Finally initialize mirror:

svnsync --username svnsync initialize file://`pwd`/REPO svn://SOMEWHERE

Now each invocation of:

svnsync sync file://$REPO

synchronizes mirror with master. Sample crontab:

* * * * *        sync-svn-repo $REPO

(which means run sync-svn-repo script with parameter $REPO on start of every minute) sync-svn-repo is simple shell script:

#!/bin/sh
repo=$1
(
    echo "---- synchronizing at `date`"
    /usr/bin/svnsync sync file://$repo
    echo "---- finished: exitcode($?)"

) 2>&1 >> $repo/synch_log.log

ssh server and keys hints

Sometimes it's hard to know why ssh server refuses to use your .ssh/authorized_keys file.
Remember that with some ssh servers (running in strict mode) your ssh configuration folder and files mustn't be accessible to anyone but you:

$HOME/.ssh                 must have mode -rwx------ (0700)
$HOME/.ssh/authorized_keys must have mode -rw------- (0600)

How to test ssh server or account configuration? If you're trying to see what ssh server is doing with your keys just execute it in following way:

/usr/sbin/sshd -Ddddde -p 8823 -oListenAddress=localhost

-D

means "don't detach"

-e

means output all log and debug messages to satderr instead of system log

-ddd

means execute in debug mode level 3

With this you have ssh server that can be used for playing with configuration without distrupting general purpose ssh service.

NetBeans slow on remote X connection

Interesting links found so far:

• FC8 Remote Java Applications Slow - discussion on some Fedora forum
• Remote access to Netbeans - not only me has these problems
• Tuning JVM switches for performance - stuff from NetBeans official site

Java 5 Trouble-Shooting and Diagnostic Guide

For record: Java TM 2 Platform, Standard Edition 5.0 Trouble-Shooting and Diagnostic Guide A very good but hidden description of hacking tools and methods useful when dealing with JVM problems.

java and OOME

Just for record. Java is absolutely unstable OutOfMemoryError. In multi threaded app you can't even do a System.exit(whatever). Because it tries to do various thing like run finalize and whatever it does it can hang up application.

If that's a server like app that can be restated by some process monitor one can use following jvm parameters:

-XX:OnOutOfMemoryError="kill -9 %p"

on unix or

"-XX:OnOutOfMemoryError=taskkill /F /PID %p"

on win32 to kill your process forcefully in case OOME.

One useful option is also -XX:+HeapDumpOnOutOfMemoryError which dumps whole heap into file before it croaks on OOME. You can analyze this dump with jhat tool that can be found in jdk1.6.0.

Related links:

• JVM Options
• jhat

subversion and output folders

Wow, first post in this blog. This post may be interesting fot those are going to import some big old stuff into subversion. Below is depiction of one of problems I've encountered today. Never ever add your 'release', 'target', 'bin' or whatever directories into subversion. If you'll import big project and for whatever reason you'll add placeholders for output directories you're buried. At first update (after build you'll) realize that 'insert name of your favorite build system' removed your bin directory (and it's .svn metafolders). Svn will immediately start to complain with something like this:

svn: 'product\library\foo\bin' is not a working copy directory

In order to fix this mess you'll have to: 1. remove directory in question

rm -rf product\library\foo\bin

2. order svn to cleanup it's internal mess

svn cleanup product\library\foo

3. update in order to resurrect broken folders

svn up product\library\foo

4. finally remove this folder

svn rm product\library\foo\bin

So if you'll happen to have 20 folders with this setup in your repo you'll have few minutes of cleanup. Avoid it!