git usage

cvs was easy to take on, even though I didn't know any version control system beforehand.

git was harder, even though I did know some systems by then.

The difference: cvs has basically one way to work with it, while with git you are much freeer in how you want to work. With freedom comes the problem of choice and the need of experience. For example git practically doesn't let you destroy any history, but sometimes it can be tough to find out how to recover from a particular mistake.

Also in the mix: When I started cvs, I had nothing. When I started with git, I had quite some history to import and to deal with.

As long as you don't do branches (and with plain cvs, you better shouldn't), cvs is just a way of sharing a common tree without risking accidential overwrites. With git there is a wealth of things you can do, and of those you can do nearly right. I don't think that I am yet in a position to foist git over a bunch of developers and to give them enough training so that they can get along without big mishaps or frustration. Especially not for windows guys.

So mostly I still use git-svn, live with the company decision to use svn, and sometimes use git hackery for special effects that nobody else needs to know about that git was even involved.

Comment notification

Blogger bites too. I just noticed that there are some comments here, and I remember turning on email notifications for comments, and relied on these.

Consequence: Only today did I even notice the existence of any comments on this blog, for which I do want to thank you, dear readers!

(Note to self: Rework the post labels.)

Priorities and signs

This was almost going to be titled 'signs are hard'. I hat a problem that a simple timer queue implementation did not quite work. Problem: Some timers seemed to vanish from the java.util.PriorityQueue, or were in the wrong order. I tried, for lack of other ideas to change the sign of the compare method, to see if I got that wrong. Letting the handler thread wait for and pick the latest timer is not a good idea. But alas, that wasn't it, and there goes the title.

Google ("java PriorityQueue remove"): Somewhat unexpectedly, the first result is not the documentation of the queue but rather exactly the report for the bug that is biting me: remove does remove the first element it finds that compares equal to its argument, not that exact object: Voila: wrong element removed; that timer never fires, I'm not getting #ticks.

Good. So now I know what's wrong and can finally implement a strategy to do fewer removes in the first place. Many timers here serve as a timeout and leave the queue not at the front but by remove. And the timeout is constant. So if a timer is set to a later time I can just leave it in the queue and reposition it when it finally appears up front.

Also there is a decision to be made whether I leave the workaround in. It's fixed somewhere in 1.6 (b51?), and I can't rely on the JVM always being that new.