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:
- Create a repository.
- Check out the repository.
- Add a file to the repository, set the svn:needs-lock property.
- Commit the file.
- Lock the file.
- Change name of the file, and check the “Keep locks” checkbutton.
- Commit the changes.
- Change the filename back to the original filename.
- 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.
Svnsync automatisation via Windows Scheduler
Filed under: Configuration Management, Development, Windows
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:projectssvnprojectsvnsync-project.bat):
svnsync synchronize http://localhost/svn/project –sync-username slaveuser –sync-password tjohej –source-password password
c:Python25Scriptstrac-admin.exe c:projectstracproject 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:
- Go to start -> control panel -> scheduled tasks
- Click Add scheduled task
- Click Next
- Click Browse…
- Browse to your svnsync-project.bat file, as described above. Double click it.
- Set name (default is ok). Perform this task: Daily
- Click Next
- Start time: 00:00, Every day, Start date: today
- Fill in username/password to run it as.
- Select open advanced properties for this task. Click Finish.
- Go to tab Schedule. Choose Advanced.
- Click Repeat task, fill in Every 10 minutes, and click Time and fill in 23:59
- Click OK.
- Click OK
- 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).
Trac on separate server from subversion
Filed under: Configuration Management, Windows
#!/bin/sh
SVNSYNC=/usr/local/bin/svnsync
$SVNSYNC synchronize URL_TO_MIRROR_REPO –username=svnsync –password=svnsyncpassword &
exit 0
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:
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.
Unsupported version control system “svn”
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.so3b. Add the following two lines to the end of the LoadModule section:LoadModule dav_svn_module modules/mod_dav_svn.soLoadModule authz_svn_module modules/mod_authz_svn.so3c. Add the following to end of the file.<location /svn>DAV svnSVNPath c:\projects\svn\testAuthType BasicAuthName “My Subversion repository”AuthUserFile “c:\projects\svn\test\conf\passwd” Require valid-user</location>
<location /mpinfo>
</location>
<Location /trac>
</Location>
Continuous integration and buildserver
Filed under: Configuration Management, Management, Ubuntu
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.
Slow grasswidow evening
Filed under: Configuration Management, Development, Frozentux.net, Personal
What do you do when you are home alone a saturday evening? Personally, I web2.0’d my life (i got facebook, a blog, remember the milk, dipity, evernote, and decided to rewrite/update my webpage). Also, I really got started building the Fokker DR.1.
To update frozentux.net, I screwed around a bit with eclipse pdt. I want to do this since I think the whole site looks pretty awful. I was ok with it “back then”, but not any more. I’ve been using eclipse for a few months to code c, c++, qt and I’ve grown rather fond of it. My first time with eclipse left me… well, let’s just say i went back for a few years to vim and loved it. Still wish there was a decent vim/eclipse plugin as i love vims command/edit mode.
I digress. Basically, what I did was Install subversion, make a copy of frozentux.net in subersion and a few other projects in there. I setup subversion with apache2. I know I suck that haven’t done this before. After that, I installed pdt, subclipse and a few other modules in eclipse and got it all working together. I think I might like the subclipse module, but still got a few things I need to find out.
I’m gonna get started on rewriting frozentux today I hope. Now, going for a walk first.