Category: Coding

Moments of love

There are certain moments in my life where I feel this love. Love and satisfaction. In these moments I do not regret at all to still work for an “underdog” version control system like [monotone](http://www.monotone.ca) and have not converted to the dark side of the moon (read: git). One of these moments was today, when I did a merge between two branches.

See, many people working with Subversion or even git are annoyed of its merge behaviour. Sometimes they even fear to merge because hell breaks loose if the source branch moved files or even directories (yikes!) around. I cannot tell how often I had to resolve tree conflicts by hand in Subversion and I also cannot tell how often git forced me to clean my workspace from uncommitted or stashed changes before I was able to pull new stuff in.

Today now with monotone, I propagated the latest changes from the [main branch](https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/) to my little [source-tree-cleanup branch](https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone.source-tree-cleanup/). The latter moves many files and even whole directories around, so one would expect merge chaos in an ordinary version control system if files inside these moved directories would have been changed, or even new files would have been added, in the main branch in the meantime, right?

Not so with monotone. It not only tracks the file identity and rename history for files, but also for directories, so the merge went flawlessly without manual intervention:

$ mtn propagate net.venge.monotone net.venge.monotone.source-tree-cleanup
mtn: propagating net.venge.monotone -> net.venge.monotone.source-tree-cleanup
mtn: [left] 4f505ed0817cef6a34e1cc404b0511426a15fef9
mtn: [right] ec9269fa9ddd7b7e2d4716610241a7577159ba9d
mtn: [merged] 1b5c865085537cebd09b5e8481fba1eebfd63a03

And the update afterwards was no exception:

$ mtn update
mtn: updating along branch 'net.venge.monotone.source-tree-cleanup'
...
mtn: adding test/func/diff_order hinzu
mtn: adding test/func/diff_order/__driver__.lua hinzu
...
mtn: updating NEWS
...
mtn: updating src/cmd_diff_log.cc
mtn: updating src/cmd_list.cc
...

(some context: `./test/func` was `./tests` before and `./src` was `./`)

Call me fanboy, but I _love_ this version control system!

monotone activity roundup

If you remember my earlier post(s) you probably ask where the highly anticipated version _one dot zero_ remains. Originally we planned to release it by the end of 2010, but we couldn’t really meet that date because we really wanted to polish a couple of things before releasing it. So what is the new plan then?

Well, we agreed that we want to release not later than by the end of Q1 2011 and if you look at our [RoadMap](http://wiki.monotone.ca/RoadMap/) you see that most stuff is already worked on, but you also see that we have quite a lot to do.

#### Core Monotone

Stephen did a great job over the last couple of weeks and reviewed our manual: He restructured the commands section, included many cross references, reworked and clarified many sections and purged old contents.

Richard, Stephen and Lapo worked on the wiki and tagged contents for certain user groups, i.e. users and developers. They also reviewed and cleaned up many pages which are often looked after and accessed. While all this is not quite finished yet, it already looks a bit better than before.

Richard and me fixed [a couple bugs](https://code.monotone.ca/p/monotone/issues/label/399/open/) that have been reported since 0.99. Right now the tracker looks more or less green with only two issues left open.

Beside the issues I’ve been working privately on the [source tree cleanup branch](https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone.source-tree-cleanup/) and got some help from Richard here as well. This branch basically moves tests and sources around and puts them into a proper directory structure, so we do not clutter the main directory with sources, documentation, utilities and other stuff. I hope I can finish this branch next – only some work on the documentation is missing – and can merge that soon to the trunk.

#### Tools

Three others news are not about monotone itself, but related to it: [usher](https://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone.contrib.usher/), [indefero](http://projects.ceondo.com/p/indefero/) and [guitone](http://guitone.thomaskeller.biz).

Richard is currently preparing usher’s sources for packaging. We learned a lot about a proper usher setup when we configured usher with indefero on our own server instance, [code.monotone.ca](https://code.monotone.ca), and while Richard used that knowledge to bring usher forward, I reworked the [sources](http://projects.ceondo.com/p/indefero/source/tree/develop/src/IDF/Plugin/SyncMonotone.php) and [documentation](http://projects.ceondo.com/p/indefero/page/InstallationScmMonotone/) of the SyncMonotone plugin in indefero.


Beside that I’m also working on including a graphical branch view to guitone. Work has gotten somewhere already as you can imagine from the screenshot, but there are a couple of subleties to fix and clean before I’ll release that actually. Packaging this version will be kind-of fun; yesterday for example I stumbled upon a crash in libgvc after I moved the Graphviz libraries into the Mac OS X application bundle (which is needed for easy deployment), Windows packaging hasn’t even be started in this regard and I also need to investigate further if and how Graphviz’ Common Public License (CPL) allows me to distribute its binaries with my binaries at all.

#### Roundup

So you see we’re not lazy, but we all have so many things to do that it will just take a little longer. So stay tuned and thanks for your continued support!

Debugging Java WebStart applications with Eclipse

The last couple of days I went through a little nightmare: I needed to debug a Java application which showed some weird behaviour only when loaded via WebStart, but not when executed within Eclipse.

[Multiple](http://www.jacoozi.com/index.php?option=com_content&task=view&id=119&Itemid=134) [internet](http://javaswamy.blogspot.com/2008/10/debugging-jws-with-eclipse.html) [resources](http://www.ibm.com/developerworks/java/library/os-eclipse-javadebug/index.html) told me to use the `JAVAWS_VM_ARGS` environment variable to tell the Java VM to either create a debug socket itself or connect to some socket started from Eclipse and then simply set a breakpoint there and wait for the meal. But nothing worked out for me, until I found two very important issues nobody wrote about so far:

* Under Java 6 `JAVAWS_VM_ARGS` seems to be completely ignored by `javaws`, on Linux and on Windows. The way to go was to use separate `-J` options in the call to `javaws` – and given a running Eclipse debug server you finally saw the threads of your running application.
* Wait, were these threads really belonging to _your_ running application? This was the second issue. Apparently `javaws` directly forks away as soon as it started and runs your application in a separate VM, which _of course_ did not get the original debug options passed. Again, some internet resources said it would be enough to load the jnlp file from the net and start locally, but actually this did not work out. The magic option to apply to `javaws` here was `-Xnofork` and finally, on the next run I saw my application’s threads in Eclipse and my breakpoints magically worked as expected.

Here is the complete command line example again (given a running Eclipse debug server on port 8000):

javaws -Xnofork -J-Xdebug -J-Xnoagent \
-J-Xrunjdwp:transport=dt_socket,server=n,address=8000 \
path/to/app.jnlp

Hope that helps someone 🙂

monotone docathon on Sunday, 18:00 UTC

The monotone team holds a “docathon” – a small documentation sprint – next Sunday, Dec 19th 2010, starting at 18:00 UTC for approx. 6hrs. During this time we meet on IRC and want to collaboratively tidy the [wiki pages](http://wiki.monotone.ca), further improve the [manual](http://www.monotone.ca/docs), update [INSTALL](https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/INSTALL) and cleanup other text-based files and more for the upcoming 1.0 release.

So if you want to lend a helping hand to your favourite version control system, just drop by on [IRC](irc://irc.oftc.net/#monotone), say hello and we’ll quickly get in contact with you 🙂

See you on Sunday!

guitone 1.0rc5 Windows installer available

Sorry that it took a while, but I got largely distracted by other things. Finally the Windows installer binary for [guitone 1.0rc5](http://www.thomaskeller.biz/blog/2010/11/06/guitone-1-0rc5-released/) is [available for download](http://guitone.thomaskeller.biz/g/download) – compiled under WinXP SP3 with Qt 4.7.1.

Please let me know if you encounter problems, for example by reporting issues in [guitone’s bug tracker](https://code.monotone.ca/p/guitone/issues/).

The fuzzy cloud

Until now “the cloud” (the computing paradigm) was for me more or less a fuzzy defined hype I missed to really “see” the advantages of: I delegate infrastructure resources to some external “hoster” and pay for that, but I instantly got this nagging fear that I’ll loose full control over my resources and data when I’d do so.

While I am (unfortunately) not in the right business for experiencing and working with “the cloud” myself, I’m still very interested in learning about the possibilities and changes cloud computing introduces, especially from the development point of view.

Today I now stumbled upon [Adrian Cockcroft](http://perfcap.blogspot.com/)’s outstanding [presentation](http://www.slideshare.net/adrianco/netflix-on-cloud-combined-slides-for-dev-and-ops) in which he outlines how Netflix, the company he’s working for, introduced cloud-based services step by step as a replacement for traditional data center services and monolithic architectures. After reading through the roughly hundred slides I can say I’m much more confident to believe that all this *is* the right direction in the future, also (but not solely) because it forces us developers to write much more domain-independent, easy servicable, stripped down code.

So if you have 30 minutes for a very good introduction in practical cloud computing, I urge you to [go ahead and read the slides](http://www.slideshare.net/adrianco/netflix-on-cloud-combined-slides-for-dev-and-ops).

guitone 1.0rc5 released

I’m proud to announce the immediate release of guitone 1.0rc5. This fifth release candidate requires monotone 0.99.1 or later. The plan is to release guitone 1.0 final together with monotone 1.0 final
by the end of this year.

Amongst some minor bug fixes, this release also features a new “server mode” with which remote monotone databases can be explored (requires compatible netsync servers with remote automation permissions).

The tarball and a Mac OS X disk image can be [downloaded already](http://guitone.thomaskeller.biz/g/download), a Windows binary should follow shortly.

As always, please [report bugs](http://code.monotone.ca/p/guitone/issues/) if possible. And I’m still looking for more translators – if you’re interested, [drop me a note](mailto:me@thomaskeller.biz).

Thanks for reading,
Thomas.

guitone Mac OS X package

Newer versions of Qt come with the nice and handy tool `macdeployqt` – I think it first appeared offically in 4.6. What this basically does is that it looks for linked Qt libraries and plugins in your binary file and copies the needed ones over to your application bundle, so your application is ready for distribution.

So far so good, this worked nicely with the [Carbon binaries](http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x) supplied by Nokia, but it stopped working properly with the Cocoa builds. While the latter are advertised as “…for Mac OS 10.5 – 10.6” and really let you build and run your application on 10.5 (yes, I still haven’t followed the crowd and updated), the `macdeployqt` does not. It depends on newer versions of `strip` and `install_name_tool` which only come with newer versions of Xcode, i.e. >= 3.2. And guess what… yes, Xcode 3.2 is of course not available on 10.6.

(Nokia has actually an older, already closed [bug report](http://bugreports.qt.nokia.com/browse/QTBUG-9318) on the issue, but I doubt they will fix the issue, they do not invest much anyways on non-mobile platforms these days and 10.7 is soon out as well, making 10.5 look even more deprecated…)

So at first I thought “lets try build a Cocoa distribution” for guitone, because I believed this could bring some speed and other improvements and I accepted that I had to kick 10.4 support out of the way for this to achieve, but this bug is actually a show stopper for me.

I’ll probably have to give away Mac packaging for guitone in the mid-term future anyways. I do not plan to upgrade to 10.7 nor to a complete new Mac (I don’t like the direction Apple is heading, but this is a different story) and Qt 4.8 will definitely no longer ship with Carbon support.

Why I do Open Source development

I was on a scrum master certification over the last two days, lead by [Joseph Pelrine](http://www.metaprog.com/blogs/about/), and beside the enormous amount of knowledge on Scrum and the not lower amount of anecdotes and stories he experienced with *[insert famous IT company here]*, he came out with one particular interesting hypothesis:

“Doing Open Source software is like having an affair.”

He argued that if people would have enough fun with their daily development tasks and would identify enough with their company, they wouldn’t have the need for doing Open Source, they would not spend their valuable time developing free stuff.

So, am I cheating my company?

Certainly I love Open Source and Free Software in general. One reason why I love it that much is because I come in contact with interesting and very smart people. For example, I learnt many things from the friendly folks in the monotone community over the last couple of years, things which I did not learn or even came in contact while doing my daily business. And guess what, my company participated and profited from this many times, because I carried a lot of this knowledge back to my day job.

Beyond learning another major thing of Open Source for me is recognition. I don’t get a lot recognition for my daily business – either because most people like my boss just don’t care how software is manufactured and how the process works (after all, its the money that counts, eh?), or because the artifact I’m developing vanishes anyway because some marketing guru of a customer decided to “well, not go into this direction any further”. Sure, the money is ok, everything is paid, but it just plainly demotivates you if you work for the trash can.
With Open Source you work on stuff you or other people demand, you get the reward in terms of positive feedback if you help them solve their problems and you get public recognition for the source code you publish.

So again, am I cheating my company? I don’t think so. Open Source allows me to think outside of the box and try new things, for all of which would be no time in narrowed sprints or busy project plans, and my company profits from that.
But yes, maybe this also opens the door for new employments in the future as well, but lets face it, doing Open Source work is often the only possibility to personally get ahead in this industry today.

monotone 0.99.1 released (updated)

The monotone team just released 0.99.1 of its version control system. This is a minor patch release which fixes two regressions:

1. If monotone 0.99 was built on x86_64, a missing variable initialization lead to a crash when parsing netsync URLs.
2. monotone 0.99 reported wrongly `12.1` as automate interface version number, whereas this should have been `13.0`.

The release can be downloaded at the [usual location](http://www.monotone.ca/downloads.php). **(Update:** A [windows installer](http://www.monotone.ca/downloads/0.99.1/monotone-0.99.1-setup.exe) is ready to download as well, thanks to Stephen.**)** Sorry for the recent release flood, we promise to cool now for a while…

Thanks for your ongoing support,
Thomas.