version control

The magic of tla cacherev

I’ve stumbled upon an annoying problem while use Gnu Arch. During the development process, one of the directories in the source tree was given bad permissions (r-xr-x-rx). With the next patch, this directory was removed altogether. That introduced a problem for tla get as it was dying with permission denied error. That happens because when tla get is executed, it gets the base-0 tree version and then applies patch-1, patch-2, … patch-N in order. Obviously, when it gets to the patch which tries to remove the directory, it fails with “permission denied” error.

The fix for this problem turned out to be very simple. tla get can be executed with user root. It won’t fail as root has enough permissions to remove the directory. But what root can also do is tla cacherev project--branch--version--patch-X. This will force arch to pack the whole tree at patch-X into the archive and use it as a unit. So, next time when someone will tla get the tree version greater or equal to patch-X, he will get it straight ahead, without all the pacthing (except for the those paches that follow patch-X).

After tla cacherev all users can execute tla get without any problems.

This technique can also be used to save some time on the tla get operation in those cases where lots of patching needs to be done.

Recursively adding files and directories in Gnu Arch

One of the little annoyances of Gnu Arch is that it does not add files and directories recursively. Not to worry, though. Here is a little shell script that can assist with that task:

#!/bin/bash

# Find all files and directories, skipping ./{arch}
for FILE in `find . -path './{arch}' -prune -o -print`
do
        # Get rid of the leading ./
        FILE=`echo $FILE | sed -e 's/\.\///'`
        tla add "$FILE"
done

Skipping the script itself is left as an exercise to the reader.

Update: Simplier method indeed is

tla inventory --source --names | xargs tla add

Subversion vs. Gnu Arch

I’ve spent some time today fighting with both Subversion and Gnu Arch. After the first few battles, it was decided that Subversion is not going to be used for the project, and that we’d go with Gnu Arch instead. There were three reasons for that.

Subversion is a pain to install. Especially on older machines. It requires a whole bunch of libraries and static compilation is not that easy. Gnu Arch is a charm to install.
Subversion does not keep owners/permissions information about files and directories. Gnu Arch does so.
Subversion does not support distributed development, which is practically a must in our case. Gnu Arch does so easily.

If you are confused about distributed development term above, here’s what I mean. We have bought a piece of software. We want to do some customizations and additional functionality development internally. Meanwhile, we also bought an upgrade plan, and it turned out that the vendor is releasing patches pretty often. Merging our internal development with vendor patches on a regular basis can be a real pain in the bottom, unless software version control system supports it natively. Gnu Arch does so and hence we’ll use it for the project.

But Gnu Arch is not perfect aswell. One of the things that we want to keep in the repository is the complete source package from the vendor. The source package consists of a couple of thousand files in few hundred directories. Files come in all variety – ZIP archives, GIF and PNG images, MS Word, PDF, RTF, and plain text documentation, PHP source code files, HTML pages, and so on, and so forth. Importing all these stuff into Gnu Arch repository turned out to be, well, slightly more difficult than it should have been.

For now, I’ll leave you on your own and give you some time to write a bash script for importing of such a source tree. You can post it in the comments. You have time until I will finish with my script some time tomorrow. I will post it here than.

Update: I decided to create a new post with the script.

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.

Subversion and file permissions

I’ve been assigned to a new project at work today. It was decided to use Subversion for version control. I haven’t used Subversion before, though I’ve read a lot about it.

Few minutes into it, I’ve got my first question: “How can I make Subversion store file permissions and ownership?”. Googling for two seconds didn’t turn out any results, so I went straight to Subversion’s IRC channel (#svn @ irc.freenode.net). Here’s the answer that I got:

Subversion does not version permissions. There exist 2 wrapper scripts which you can use instead of “svn” for commit, checkout, update, etc., and store permissions in properties. They are: asvn and svn+perms. Last but not least there is a patch which adds the functionality into the svn core.

(I edited it a bit for the better linking).

Also, I’ve also been pointed to this blog.