Dangling locks in the Subversion tree

I recently ran into another rather peculiar and interesting case with subversion. As I've already explained, I don't have actual physical access to the subversion servers we are perusing for our project. We use TortoiseSVN for access to the repository on our local systems.

My boss was working with some excel and word files checked into the repository. He had template.xls locked as he was working in it, he decided to rename it to a template, so template.xlt it is (and checked in). After doing some more work, he decided this was a bad idea, so he changes it back to template.xls, and tries to check it back in again... no luck, it wont work.

15-20 minutes worth of investigation later, we found the problem. TortoiseSVN had been configured to always check "Keep Locks" on commit, hence the client kept the lock when he commited the template.xls deletion. To fix this problem, run svnadmin lslock and then svnadmin rmlock the file in question. Please note that this requires actual access to the physical subversion repository. Http or svnserve will not do in other words.

A step by step on how to cause the Dangling lock problem -- All of the actions are done via TortoiseSVN interface:

1. Create a repository.
2. Check out the repository.
3. Add a file to the repository, set the svn:needs-lock property.
4. Commit the file.
5. Lock the file.
6. Change name of the file, and check the "Keep locks" checkbutton.
7. Commit the changes.
8. Change the filename back to the original filename.
9. Commit the change. This step will fail.

This is a rather funny problem imho :-). We finally managed to get it fixed after contacting the IT department and sending them the command. 10 minutes to cause the problem, 20 minutes to analyze it, 20 hours to wait for the fix. Sometimes there should be less depth in organizations.

In windows, noone hears you scream

As you've all noticed, I've been working overtime with Windows as of late. I'm working in the embedded development industry, and wherever I turn, there is windows. To be honest, I don't get this industry and why the hell they keep running in this environment. Most of the people I've met in the trade are brilliant minds and know what they are doing, but the business in general are very backwards refusing to let go of things.

Also, another reason for the entire trade being stuck in such a fashion is all the tools produced. You have a market catering to the same market with software and tools, developing for a single common development platform -- Windows. And you have product lifetime to take into consideration.... There are still a bountiful of products out there that was developed before windows 3 was created.

All of this is creating a rather stagnant trade where it's hard to get a move on, test new things, do something differently. Just take my last few weeks of working with subversion/trac/cruisecontrol on windows. Had I known just how much work I would be forced into just because someone else decided that we run it on Windows XP, I would have protested loudly.

I can't simply get rid of this horrible abomination of an operating system in this trade, thats the sad but simple fact as of today. Sure, I've managed to get trac and cruisecontrol into the project, and we use subversion since before. But, I still need Windows for proprietary development environments, proprietary fileformats from customers, proprietary software from proprietary software companies, and so forth and so forth. And before you say anything, unfortunately I'm really stuck this time, proprietary IDE and compilers for weird hardware. Every time I touch an embedded project, it's the same thing "oops, we gotta use this processor or that dohicky which requires software Y which requires Microsoft Windows".

What's just taken me 3 weeks in Windows -- Basically, setting up subversion/svnsync/trac/cruisecontrol and some small work around that -- was accomplished in that time, even though I did the same in less than 2 days just before in Linux. As we're building for target via cruisecontrol, we where stuck with using Windows as the compilers where proprietary...

I'm a Unix person by soul, I love it, it's natural to me, it's my home. It's where I come from! I feel like I'm screaming at this insanity asylum that is Windows, but nobody is listening to me. The entire Operating system is befuddled with incompetence, idiocy and bad design choices.

Svnsync automatisation via Windows Scheduler

Recently I've been setting up for a project, as you might have noticed, and one of the problems we ran into was the fact that we have a centralized subversion repository. We don't have access to control or install anything on the actual server unfortunately, so hence we can't install trac on that system, as previously explained. The solution is to sync the main subversion databases to the trac server as previously explained.

A secondary problem arising from this, is that we can't actually change the hook files of the master repository. The solution to this, is to add a synchronizing scheduler. As I was stressed, and had no time to deal with this properly, I had to run with the Windows Scheduler of all horrible solutions. The following explains how to set it up.

Windows Scheduled synchronize Task

Warning! The windows scheduler does not start automatically when you reboot etc. If you do this, the task restarts at it's start time, so if it's set to run at 00.00 every day, and then every 5 minutes, it will restart and start running at 00.00, not as soon as the machine is started up again. This is pure evil.

A scheduled task is set up as follows, create a bat file (ie, c:\projects\svn\project\svnsync-project.bat):

svnsync synchronize http://localhost/svn/project --sync-username slaveuser --sync-password tjohej --source-password password
c:\Python25\Scripts\trac-admin.exe c:\projects\trac\project\ resync

The Second line unfortunately has to be done to resync the new changes with the trac database. After this, create a scheduled task in windows as follows:

1. Go to start -> control panel -> scheduled tasks
2. Click Add scheduled task
3. Click Next
4. Click Browse...
5. Browse to your svnsync-project.bat file, as described above. Double click it.
6. Set name (default is ok). Perform this task: Daily
7. Click Next
8. Start time: 00:00, Every day, Start date: today
9. Fill in username/password to run it as.
   
10. Select open advanced properties for this task. Click Finish.
11. Go to tab Schedule. Choose Advanced.
12. Click Repeat task, fill in Every 10 minutes, and click Time and fill in 23:59
13. Click OK.
14. Click OK
15. Done.
    

This could most likely be done from cruisecontrol, but as stated, i'm stressed. I hate windows by now (at/cron is just sooo much nicer to handle).

Linux iMON pad remote controller with lirc

Introduction
In short, the SoundGraph iMON PAD that came with my SilverStone LC20 doesn't work very well with the default ubuntu 8.04 installation. I've previously discussed how to get the VFD running, and am now turning my attention to the remote control and how to get it decently working in mythtv with lirc.

Let's start by looking at the following image:
In short, red files are "main steps" which the "packets" flow from the remote control, and finally reaching lircd where they are converted from a binary stream into something intelligeble (with the help of the lircrc file, which specifies names for the different hex codes).

blue boxes are configuration files, green boxes are "users" of lircrc -- ie, they will connect to lircd and receive all the updates from lircd as needed. Finally, magenta boxes are different things needed to build to get stuff running.

Installation
Everything will work out of the (ubuntu 8.04) box more or less, except for the big blobby nice mousepad on the remote control. That one is a mouse -- sort of -- and doesn't work at all for me, your mileage may vary however (ie, it didn't work for me, it might change fast)

Install Xorg, mythtv, mplayer, linux-kernel sources (needed later) and lirc via apt-get or your prefered frontend. Configure the packages, start xorg and make mythtvfrontend start from the .xinitrc if you so wish, and then start via the startx script, or rather make it start up as you feel most comfortable with. I'm an old fart and I like my startx.

Once all this is set up, all things should work, except the remote control, as already said. Most buttons will work, but not the big blobby knob (a.k.a. mousepad).

HACK
Well, it's time to hack the horrible hack I guess. Download lirc-0.8.3 from www.lirc.org. Also, download the pad2keys patch from http://brakemeier.de/electronics/vdr/lirc-imon.html.

1. Unpack the lirc package.
2. Patch the lirc package with the pad2keys patch (it will most likely fail with some chunks, just look at the patch, and add the code manually, are you a hacker or not?!).
3. Configure and make the lirc package. Don't install it.
4. run uname -r, note your kernel version (2.6.24-19-server for example).
5. run "locate lirc_imon.ko" (have you updated your locate database? man updatedb, hint hint). If there are more than one in the list showing up, find the one in /lib/modules//blah blah.
6. Copy lirc-0.8.3/drivers/lirc_imon/lirc_imon.ko to the file you found in step 5, and replace the old one.
7. Either reboot, or if you know how to rmmod lirc_imon.ko and modprobe the new one. This might fail if you followed my previous post on islcd=0 etc, if you did, remove that line again.

Don't forget to edit your lircd.conf with the new IR codes from the brakemeyer.de webpage. Set PAD key's to good values, such as this:

Up 0x690281B7
Right 0x688A81B7
Down 0x688291B7
Left 0x6A8281B7


Finally add them to your lircrc in a good way, such as this:

begin
prog = mythtv
button = Up
config = Up
delay = 2
repeat = 1
end

begin
prog = mythtv
button = Down
config = Down
delay = 2
repeat = 1
end

begin
prog = mythtv
button = Left
config = Left
delay = 2
repeat = 1
end

begin
prog = mythtv
button = Right
config = Right
delay = 2
repeat = 1
end

So, you're now a hacker of immense proportions. Celebrate with some mead and grow a beard like the rest of the hackers ;-).

Trac on separate server from subversion

It is possible to have Trac on a different server than the subversion server, albeit a bit convoluted. This is slightly stolen note from http://blogs.open.collab.net/svn/2007/08/mirroring-repos.html

Set up the master subversion server as you would normally. We will get back to this one.

On the trac server, install subversion etc as well. This server will rely on svnsync to become a secondary/mirror subversion server. It must not be used for checking in or working against, it is purely a repository for reading.

Set up trac and all other tools required on the mirror server.

Now, you need to set up user accounts on the mirror server. To start with, create the mirror subversion repository, it will be empty to begin with:

svnadmin create MIRROR_REPOS_PATH

After that, create authz authentication files for the repositories to stop anyone from writing/working against the mirror repository, such as the following:

[/]

* = r

svnsync = rw

You could extend this by writing hook scripts blocking anything but the svnsync user.

If the master subversion repository is live while adding the trac database, all of the following must be done during server maintenance window (ie, close it down from any kind of access, except the mirror machine).

Once all that is done, its time to initialize the the mirror server with the master subversion repository (ie, move over the data).

svnsync initialize URL_TO_MIRROR_REPO URL_TO_MASTER_REPO --username=svnsync --password=svnsyncpassword

And once that has successfully been done, do as follows:

svnsync synchronize URL_TO_MIRROR_REPO --username=svnsync --password=svnsyncpassword

The final step is to either add a scheduler (cron.d) script, or a post-commit hook script running the following:

# Example for synchronizing one repository from the post-commit hook
#!/bin/sh
SVNSYNC=/usr/local/bin/svnsync
$SVNSYNC synchronize URL_TO_MIRROR_REPO --username=svnsync --password=svnsyncpassword &
exit 0

Preferably run it from post-commit as it gives better refresh rate.

You can now run the trac against the mirrored subversion server.

Trac on windows

Trac is a rightfull bitch to install on win32 as it requires very specific version matching of packages. This is a long winded installation note with the more or less latest versions available as of this writing.

I'm hoping to get working on TortoiseSVN and Trac integration once this is done (ie, make tortoise automatically set variables etc sent in change notes, which can hence update the issue tracking systems in trac and so forth. The way of working is really really sweet imho, and I think it could be a really nice way of working. I'm just sad that I have to set all this serverstuff up on windows though.

Let's begin with a list of all the installation files used:

python-2.5.2.msi

setuptools-0.6c8.win32-py2.5.exe

py25-pysvn-svn150-1.6.0-975.exe

svn-python-1.5.2.win32-py2.5.exe

Genshi-0.5.win32-py2.5.exe

Trac-0.11.win32.exe

WampServer2.0c.exe

CruiseControl-2.7.3.exe

TortoiseSVN-1.5.3.13783-win32-svn-1.5.2.msi

WampServer2-APACHE229.exe
svn-win32-1.5.2.zip
mod_python-3.3.1.win32-py2.5-Apache2.2.exe

These packages should be fairly simple to get started with. Install them straight on, in the order mentioned.

python-2.5.2.msi

setuptools-0.6c8.win32-py2.5.exe

py25-pysvn-svn150-1.6.0-975.exe

svn-python-1.5.2.win32-py2.5.exe

Genshi-0.5.win32-py2.5.exe

Trac-0.11.win32.exe

Install the above packages in that order. Some errors i ran into:

Unsupported version control system "svn"

I accidentally used svn-python-1.5.0.win32-py2.5.exe. It also complained about not finding SSLEAY32.DLL which threw me off course, looking for the wrong solution.

Secondary applications

On top of this, the following applications where installed (not yet configured/set up).

WampServer2.0c.exe

CruiseControl-2.7.3.exe

TortoiseSVN-1.5.3.13783-win32-svn-1.5.2.msi

WampServer2-APACHE229.exe

The Apache2.2.9 must be installed before svn-win32-1.5.2.zip files are, and the .so files must be put in 2.2.9 as that package will not run on Apache2.2.8. Apache 2.2.8 with svn-win32-1.5.2.zip will die silently without hint as to why it died.

Once all of the above is installed, create a svn repository in c:\projects\svn\test (create directories, and then right click test and choose TortoiseSVN -> Create repository here.

Now create a trac database in c:\projects\trac\test\ by running

c:\python2.5\trac-admin.exe c:\projects\trac\test\ initenv

Answer the questions asked by trac-admin.exe. To test the trac at this point, run tracd.exe per ordinations from trac-admin.exe.

svn-win32-1.5.2.zip

Contains required files to make dav_svn work in apache2.2, edited extract on how to install:

For an Apache server here's the essentials:

1. Copy bin/mod_dav_svn.so and bin/mod_authz_svn.so to the Apache modules directory.

2. Add the Subversion/bin directory to the SYSTEM PATH.

3. Edit the Apache configuration file (httpd.conf) and make the following changes:

3a. Uncomment the following two lines:

#LoadModule dav_fs_module modules/mod_dav_fs.so

#LoadModule dav_module modules/mod_dav.so

3b. Add the following two lines to the end of the LoadModule section:

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

3c. Add the following to end of the file.

<location /svn>

DAV svn

SVNPath c:\projects\svn\test

AuthType Basic

AuthName "My Subversion repository"

AuthUserFile "c:\projects\svn\test\conf\passwd" Require valid-user

</location>

Add users to passwd file above:

C:\wampbin\apache\apache2.2.9\bin\htpasswd.exe -b \projects\svn\test\conf\passwd myuser hejhej

Finally installing Trac in apache2.2

mod_python-3.3.1.win32-py2.5-Apache2.2.exe

To run trac via apache, you need the above module for apache as well. Once this is done, add the following to modules section of apache:

LoadModule python_module modules/mod_python.so

To test the python installation add the following to the end of your httpd.conf:

<location /mpinfo>

SetHandler mod_python

PythonInterpreter main_interpreter

PythonHandler mod_python.testhandler
</location>

And if that works, test the following:

<Location /trac>

SetHandler mod_python

PythonInterpreter main_interpreter

PythonHandler trac.web.modpython_frontend

PythonOption TracEnv "c:/projects/trac/test/"

PythonOption TracUriRoot /trac
</Location>

Further reading

http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/contrib/issue-tracker-plugins/

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html

http://trac.edgewall.org/wiki/TortoiseSvn

http://trac.edgewall.org/wiki/TracOnWindows

http://ifdefined.com/blog/post/2007/10/BugTrackerNET-integration-with-Subversion---design-choices.aspx

Ubuntu 8.04 lirc_imon VFD's

I got a silverstone LC20 chassi with a built in iMON vacuum fluorescent display (VFD) and IR remote control. I recently upgraded to Ubuntu 8.04 from 7.10 -- yes I know, I am a bit late, but generally you don't have to deal with kinks like this one when that happens.

Ubuntu 7.10 -> 8.04 changed the behaviour of the lirc_imon module pretty little, yet radically. The old default was to treat all iMON driven screens as VFD's, but it now defaults to treat all iMON modules as LCD modules instead.

This results in tons of errors being pumped out (10's-100's per second), like this one:

Sep 9 21:35:00 fs1 kernel: [ 71.481262] /var/lib/dkms/lirc/0.8.3~pre1/build/drivers/lirc_imon/lirc_imon.c: lcd_write: invalid payload size: 32 (expecting 8)

Also, the VFD will not work. To make a long story short, to fix it, you need to tell the kernel module that the VFD is in fact a VFD and not a LCD, by giving the kernel module the option islcd=0. For example, in /etc/modprobe.d/options:

options lirc_imon islcd=0

I hope this helps anyone out there. I will soon try to have something together on getting the iMON PAD working properly. The basics was simple to get working, but the "mousepad" has been a general pain to get up and running properly.

If god is omnipotent, why did he need to rest on the 7th day? Shouldn't he have been fixing his errors?

Qt presentation tomorrow

So, I'm holding a brief Qt presentation on a demo i made a few weeks back. It's pretty, and got a ton of stylesheets on it. Going down tomorrow at work. Hopefully people will be a little bit interested at least. It's not that often I dare get my ass up there behind a podium, or speak up at all for that matter.

To be honest, I don't know why really, I just hate being in front of people talking and possibly saying anything that might be wrong. Of course, there's a reason why I'm doing the presentation, and not someone else. I'm the only one with any substantial experience at all of this subject, so why not basically.

Also, I'm feeling horribly stressed as of late. I started on a project last week, and it's getting to me. Need to take a minute, sit down, and calm down.

IKEA and stuffs

Once again we've been to IKEA. Once again, we got back home with a ton of stuff. Picked up a lot of smaller things we needed, lights, bowls, etc. Also, we went by jysk and finally found a half-decent tv-bench. We didn't really love it, but agreed that with some white paint, we could actually stand it for a year or two. It's taken almost a year of bickering to finally find a tv bench that we both can agree to buy. Hilarious :).

To sum it all up as simple as possible, we have no really good space to put a tv at, either its a bad angle towards the sofa, or it's in the middle of the floor, or we have a too small space for most tv benches. Also, I have a htpc + a huge amplifier, both are ... not quite sure, but both chassis looks to be based on 4U rack-mountable machines (H16xW43xD43cm approx), and both need to fit in the tv-bench. Annoyingly, almost 90% of all tv-benches havent been planned to fit that size HTPC/amplifiers. It's a standardized size, sure it's the absolute largest standard size you will see on this type of hardware, but it's still standard.

Let's take an example, the chassis of both machines are 16cm high. Out of maybe 10 benches we found that have "high" shelfs for dvd's etc, only 1 or possibly 2 could fit a 16cm machine. The rest where around 15,5cm, or sometimes simply not deep enough, etc. Why the hell is there a common form factor, and the designers of furniture can't deign themselfs to look it up and design the furniture to hold the common hardware?

Anyways, we did find a few benches that could've worked... except... they where so freakishly ugly it's not even funny. Take EINA avlastningsbord for example. Looks decent on the pictures there, but in reality the material/finish looks like cardboard box that's been standing out in the rain and then dried up. Lerberg was actually a candidate, just because it was so cheap, and we only need to use it as long as we live in this apartment. Check out the max load of it though, 10kg?? We couldn't even have put the tv on it, and we only have a 20" LCD tv. Not to talk about the 25kg htpc or 16kg amplifier. Flärke was another really cheap option, except... it simply doesnt fit with our furniture, and it doesnt look very good, AND machines doesnt fit in the bench.

Either way, we found a bench finally - at jysk. They didnt have it in store yesterday, so hopefully I'll be able to pick it up today at another store. Can't find any pictures of it, so just saying it looks half decent at least :).

Continuous integration and buildserver

So, I finally got around to trying out continuous integration and got a buildserver at home. Ok, not much use on any 1-man projects, but should be good enough for some testing at least. I'm currently using cruisecontrol for it, and so far so good. I've got a few points I sincerely react against, but I'll get back to that a bit later.

For those not knowing what continuous integration is, I suggest reading the above link. Basically, when you run a project, you always run into some "final" integration problems. People have coded each on their own side, and you wind up having to "integrating" the code so that it all works as supposed. In the one extreme, you have everyone coding on their own tree from start to end, and then you finally have an integration session. In this shitty situation, you have no clue how long it will take. On the other extreme, you have "perfect" continuous integration, where every single line of code is tested and checked that it doesnt screw things up.

A buildserver such as cruisecontrol is an excellent tool for doing "good" continuous integration. What it does is as follows, it connects to your central code repository, checks for any changes. If there was changes, it downloads them, and then rebuilds the project(s). If you have done it properly, you also have a ton of tests that you can run on the project. This is then reported or output in several different ways. Did it fail, did it succeed, and so forth.

I might be able to convince my new project manager to use a cruisecontrol server for the project I am working on at the moment, and he sounds like he likes the idea. We just need to consider everything for this project, and I need to figure out just how it works and how to configure it etc etc etc =) . Either way, I think it will be interesting to find out more about this type of development, and to see if it actually changes the development in any large way.

Oh, yes, I currently got two things I need to figure out with cruisecontrol. If I got it right, it doesn't support GNU Make. Not supporting make seems... well, to be honest, totally stupid. It's been one of the biggest make systems for 20 years or more, so there's bound to be like 500000+ projects out there already running Make. I know it's an old system, but it works, and it's there already.

The second thing, I'm not totally certain of this, but subversion support seems to be abysmal. I need to look more at it however to find out the lay of the land or something.

Re: "Miljövän rasar mot flygshow"

http://www.gp.se/gp/jsp/Crosslink.jsp?d=113&a=442174

I need to comment on this news story as it really annoyed me.

I've personally grown up with airplanes and airshows very close to me as my father was a pilot, I have quite a few old friends that are pilots, and I've always been interested in airplanes and I admit that this might have coloured my perspective very heavily. However, the hypocrisy and bullshit, if you excuse my language, that Lotta Holmberg spews forth is just plain wrong.

Before she even considers throwing stones in her own glass house, she should contemplate how she herself is living. She's even so mentally deficit as to admit that she hasn't even stopped her "yearly trip to the sun". Now, let's do some really simple math on this.

Let's consider how many people get anything from a trip with a charter airplane "to the sun", approximately 200-500, let's say 400 to err on her side. Average trip time from this country to "a place in the sun" would be approximately 5-6 hours airtime, so a grand total of 12 hours both ways. Split the airtime per passenger, 12/400 which turns into 1.8 minutes per person on the airplane.

Now, let's consider the airshow. There was a grand total of maximum 6 hours or so of airshows per day, average of 3-4 airplanes in the air at all times (rounding to 4 to be nice to you), so a grand total of 6*2*4 = 48 hours in the air during the whole airshow. 45000 persons visited the airshow and had a great time, making for a total of 48/45000 hours per person and which turns into... tada, a massive 3,84 seconds airtime per visitor.

To make it simple, let's make the assumption "all airplanes turns out as much green gases as any other" (your charter aircraft is gigantic in comparison and shiny new with perfect green engines (yeah as if, you freakin mooch going with the cheapest 30 year old crap airplanes on the market and still flying commercially), while "mine" at the airshow are very small, but at the same time very old so probably having a bad efficiency with a big exhaust of gases in comparison to their engine size). So, 1.8 minutes = 108 seconds, divided by 3.84 seconds, 28.125x less gas output per person in comparison to your "yearly trip to the sun".

I got about 50 other reasons why airshows are a good thing and needs to be there, and why you should keep your mouth shut. Please stop throwing stones in a glass house and stop putting your feets in your own mouth.

Now, if you excuse me, I need to visit 420 airshows to use up as much green gases as you have done with your "yearly trips to the sun" -- calculated based on you being old enough to have been on 15 "yearly trips to the sun" vs Göteborg Aero show.