svn:ignore property, STS and Subversive

Working with a combination of Springsource Tool Suite, Subversion and the Subversive plugin, one of the things that really bugs me is the issues I keep on getting as a result of messed up source control of the "target" directory.

This directory typically holds all of the compiled classes as well as a stacktrace log and a few other things. In general it never really needs to be put under version control.

One of the things I keep forgetting to do, that frustrates the hell out of me is to set the svn:ignore property as soon as the repository is created. You see, without this property set, the target directory is submitted (added) to version control and once it's in there, there's no (easy) way of getting it out, as the Subversion documentation says:

"...Once an object is under Subversion's control, the ignore pattern mechanisms no longer apply to it..."

And even if you set the "svn:ignore" property on the directory, it still probably won't work properly. Instead committing all of the class files and so forth that you couldn't give two craps about.

All this is well and good, but could be written off as a minor problem, if it weren't for the fact that when you try to revert your changes, Subversion could very well pick up "conflicts" between the class files, and in fact can put you in a situation where you're struggling to get a functional checkout of the repository, simply because of the "target" directory.

The problem seems to be with the nature of the files being stored in the directory being constantly deleted/recreated etc... which seems to screw up Subversion. At the moment there doesn't seem to be a fix for the issue i.e. every time I see the problem, I just manually manage the conflicting files.

Book Review: Version Control with Subversion

I just finished reading the online version of the Version Control with Subversion book, which is available for free at the link provided. The book was an incredible help in teaching me the ins and outs of subversion. The only thing I can say that was perhaps not as great as it should have been is that it sometimes went into too much detail, exploring too many of the options and fringe use cases.

While I have managed to set up a repository, make it available over WebDAV and have a Redmine install use it, all without having read this book, this was mostly done by following a recipe. This means that I didn't delve too much into the workings of the software or all of the different configurations that you could have. This area is where this book shines. It tells you how you could have done things differently and the possible reasons for doing so. I personally found several configuration options which I have tweaked on my own Subversion/Apache setup to make it more secure and efficient.

Overall, a good read and while I can't say for sure that everything in this book will be relevant to you, I can say for sure that nearly everyone using Subversion will find something in this book for them.

Installing Redmine + SVN on Ubuntu 10.04

I've got a new workstation pc. It's not much (no hardware supported virtualization, onboard graphics) but it does the job. I've decided to take it and basically turn it into the ultimate development machine. That is to say, start right from the beginning and do things properly. The last sentence probably means a lot of different things to a lot of different programmers, so what does it mean to me? Well basically:

* Ability to access the machine remotely (Dynamic DNS + SSH/Web access)
* A Version Control System (Subversion, thank you very much)
* Project management/issue tracking software
* Development web server + database (Tomcat & MySQL)

So, today I will be writing how to get Subversion + Redmine up and running on Ubuntu 10.04. Partly to help someone out there that might be having the same problem and partly because I'll probably be having to install it again in the future and having a written record might save some time :-)

I've installed both Subversion and Redmine from the repositories and generally used the sample configuration which came with the packages, with a little bit of tweaking of course.

Installing Subversion is as easy as running:

sudo apt-get install subversion libapache2-svn

Next, I mostly followed the subversion install instructions found on the ubuntu wiki page, setting up a private repository. The wiki writeup is excellent, telling you how to get up and running quickly, whether you use subversion over HTTP/HTTPS/SVN/SVN+SSH.

Redmine was a little more tricky to install, although still a lot easier than I remember it being before it was in the repositories. Start by running:

sudo apt-get install redmine redmine-mysql

If you don't use MySQL, use one of the alternates (redmine-sqlite, redmine-pgsql). The sample configuration for Apache can be found at /usr/share/doc/redmine/examples/. I used the 'apache2-alias.conf' file by pasting it into /etc/apache2/sites-available/redmine and running:

sudo a2ensite redmine
sudo /etc/init.d/apache2 restart

After this I got an error saying that one of the apache directives was in the wrong place:

... waiting Syntax error on line 14 of /etc/apache2/sites-enabled/redmine:
SocketPath cannot occur within section


I then tried moving the directive to the /etc/apache2/mods-available/fcgid.conf, however this ended up giving me a different set of errors in the apache error log:

[Sun Feb 13 16:23:33 2011] [error] (13)Permission denied: mod_fcgid: couldn't bind unix domain socket /var/run/redmine/sockets/default/6126.28
[Sun Feb 13 16:23:33 2011] [warn] (13)Permission denied: mod_fcgid: spawn process /usr/share/redmine/public/dispatch.fcgi error

Finally, I commented this line out from both sections and was able to get redmine going without fcgi (Later I realised that I had installed passenger and it was running and that this was probably the reason that fcgi kept throwing the errors.

So, then you can navigate to http://localhost/redmine/ and configure the admin user (default username/pass is admin:admin) and you should have a working Redmine install.