A Few Useful Things About SVN

There is a nice thing called SVN. Those unfamiliar - read here [1]. SVN, as is known, consists of two parts - server and client. The server stores all changes. If you have got to the point where an SVN repository has been assigned (or created), that is a good sign that everything is fine with the server :) The client is where everything happens and where the working copy is stored - the one the developer actually works with.

1. Adding new files. If you end up working in a Linux environment (console), two things are missing from the existing SVN commands - checking which files have been added (on the assumption that we are not typing svn add each time) and which have been removed.

So:
svn status | grep "^?" | awk '{print $2}' | xargs svn add

If file names contain spaces, this command sequence will be handy:
svn status | grep "^?" | sed -e 's/? *//' | sed -e 's/ /\ /g' | xargs svn add

While preparing this article I also found this:
svn add . –recursive

I haven't tried it.

2. Converting from an SVN working copy to a non-working one. In short - removing .svn directories. This could be useful if you need to copy "dirty" code into another SVN working project, or to heed the wise counsel that .svn directories should not be exposed on a public server.

find . -name ".svn" -exec rm -rf {} ;

3. On the server, export the project on each commit (for example, to a public directory). This trick will work if you have sufficient permissions to modify the SVN server configuration. So, this concerns SVN hooks.

When creating a new repository on the server (svnadmin create), various configuration files and directories are created. One such directory is hooks.

Then, inside hooks, we rename post_commit.tmpl to post_commit, grant execute permissions and make the necessary edits. Don't forget about permissions either.

The process is rather opaque, so if something goes wrong - the only option is to log.

[1] http://en.wikipedia.org/wiki/Subversion_%28software%29