Today I've rewritten most of my "laySVN" layered subversion tool. Tests had shown that most of the time was spent calling the "status" command of the underlying subversion client. This is probably due to locking, and the workaround is pretty simple: avoid calling it on single files, instead run it on the whole repository at once.

This of course requires major changes to the code, so I've started a rewrite. I've already applied for a alioth project for it, I'll make the source available via svn.debian.org soon.

"Layered subversion" means that you basically checkout multiple subversion repositories on top of each other. A file found or ignored in an "upper" layer will not be checked out in lower layers; ignoring a file in a layer will effectively "hide" it if it were in lower layers.

This is an interesting alternative to branching. In branches, you have to "carry forward" changes from one branch to other branches. The base case - merging changes from a "lower" layer into an "upper" layer is usually quite easy. The other direction can get quite messy however. Assuming that multiple files were modified in the checkout, how are you going to commit these changes to the correct branches? Basically you'll have to commit the files to the correct branches, then do the merging magic.

Along comes laySVN, where this common usage pattern is much easier. Changes will automatically be committed to the highest "layer" the file is in. A checkout will update the file to the version of the "highest" layer. The only case which is a bit more complex is when you want to make changes to a file on a different layer. Then you actually have to "add" the file to the appropriate layer. Not really difficult either, is it?

A different name for "layered subversion" would probably be "difference branches", which are very similar.