Static Subversion for Red Hat 6.2

I’ve heard a few harsh words about Subversion before. Mostly these came from sysadmins who complained about all bits and pieces Subversion requires to work properly. Some mentioned that it is not trivial to compile with the set of options that is different from the default.

Today I spent about three hours together with The Master of Strace trying to make Subversion command line client svn work on one of our old machines that runs Red Hat Linux 6.2. The only way to success, it seems, was to compile the static version of svn. Since we needed support for https:// URLs, we had to build with OpenSSL. OpenSSL is not trivial to compile statically too, because of it enourmous love of Kerberos5. While trying to make it work we also jumped through a number of versions of Subversion and other components.

Finally, we managed to build everything. In case you’ll ever need a statically compiled version of svn (from Subversion version 0.17.1 (r4503)), you can get it here (the binary is about 7 MB):

/usr/local/bin/svn

As far as I am concerned it works just fine. It runs on Red Hat Linux 6.2 and can work (import, checkout, commit, etc) with repository running on one of the recent versions (1.1.4 if I recall correctly).

Needless to say that today I’ve heard a few more not-for-kids-ears words and phrases towards Subversion developers.

Finding all executable files on the system

find is one of the most useful and feature rich commands in Linux. Sometimes it is not that obvious which parameters should be fed to find for this or that behaviour. The manual could surely use some work.

Today I was trying to figure out how I can find all executable files on the system. The manual suggests that I use the -perm option with the specification of the mode. Figuring out the mode might get to you, so here is the example:

find / -type f -perm +0111

One could specify any mode what-so-ever. Just remember that 1 stands for ‘execute’, 2 stands for ‘write’, and 4 stands for ‘read’.

KDevelop vs. Microsoft Visual Studio .Net

This article at NewsForge.net compares KDevelop and Microsoft Visual Studio .Net. It suggests that KDevelop is an often better option, even though it still has a few sharp edges waiting to be rounded. This review is mainly based on functionality needed for C and C++ programming.

I myself don’t use neither KDevelop, nor Microsoft Visual Studio .NET thus I can’t really say if the article holds any water. But more publicity can’t hurt KDE project, so I decided to link to it. Let me know what you think about the review. Even though I use Vim practically for all my programming, I am still interested in other IDEs and editors.