Category Archives: Musings

Installing Subversion plugin in Eclipse

Sometimes Eclipse really sucks. Today I wanted to upgrade my subversion plugin and ended up wasting a lot of time on it.

How to upgrade a plugin in Eclipse?

  • Help / Check for Updates
    • This will scan all your plugins, taking a long time, when I want to upgrade one specific plugin
    • In this case it’s also pointless (as I found out later), as the Subversion plugins are on separate upgrade sites per version (different site for 1.6, 1.8, etc)
  • Help / Install New Software
    • It seems this is the way to go, but why so non-intuitive name?

Well this didn’t work. I got all kinds of errors that didn’t make much sense:

  • “Cannot install XYZ plugin because it already exists. Upgrading instead.”
    • Except it could not upgrade, due to some conflicts in dependencies which again, didn’t make much sense.
  • Next I tried uninstalling all Subclipse related plugins to resolve the conflicts.
    • The uninstall seems to work successfully, but when I try again the install, it still complains that XYZ plugin is still installed.
  • Next I tried removing all the files in ECLIPSE_HOME/plugins that seem related.
    • Then I get stuck when downloading the new jars, “read timed out”
      • … despite the fact that I can download those files in a browser
      • … despite the fact that some of the mentioned files are already downloaded in the plugins directory
      • … same result even if I manually download the jars and put them in plugins directory

The final solution was to download the ZIP file from the Subclipse site and install locally, from here:

Eclipse is (usually) pretty great. If only they could iron out these kind of issues already. They existed for as long as I can remember…

Why use git with the centralized Subversion repository at your workplace

Subversion is pretty mainstream these days. Luckily, git can work with a Subversion repository just fine. So, just because your workplace is using Subversion as the central repository, you can work with it using git if you want. Using git you can checkout from Subversion, use it locally enjoying all its benefits, and occasionally commit your work back to Subversion.

Let me give you some real practical reasons why you absolutely should use git instead of Subversion on the client side:

  1. With git you have the complete revision history locally. History operations do not need network access, and are therefore very fast. (You do know that git is the fastest version control system out there.)
  2. All commits are local, not automatically applied to the central repository. This way you can break down large tasks to several smaller commits which, being local only, will not have side effects on others. Temporary instabilities introduced by your changes as you make progress will never affect your coworkers. After your feature is completed and stable, you can push your local commits to the central Subversion repository.
  3. Creating local branches is easy and efficient. In git you can have multiple branches living inside the same working directory, and switch between them easily. This makes it very easy to switch between different tasks, or trying different implementations of the same task, without creating unnecessary copies of the project’s workspace. Subversion handles branch operations very poorly, so you might not be used to using a lot of branches. Git handles branch operations very well, and you once you get used to branching often, you will benefit greatly from it.
  4. Subversion litters all sub-directories of the project with .svn directories. Git works differently, there is a single .git directory in the project’s root directory. Among other things, a nice side effect of this is that you can easily do things like grep -r.

In short: if you are using a Subversion client instead of git, you are really missing out on a lot of benefits git could bring to you.


  • Git is cross-platform (works on Linux, Windows, Mac)
  • There is a nice plugin for Eclipse, and probably most other major IDEs as well
  • On Windows it comes with a superb bash terminal and other core unix tools, which is a lot leaner than a cygwin beast when all you need is bash, awk, sed and perl…

What’s the catch?

  • Eclipse integration does not work as well as Subversion:
    • The Team Synchronization function may not work well, depending on the repository. In particular if the line endings in the project are not consistent, using a mixture of windows-style and unix-style line endings.
    • I don’t know how to do git svn rebase and git svn dcommit from Eclipse itself, so you might need the command line for that.
  • You really have to spend some time to learn it properly. Git has a unique way of thinking which is different from Subversion. You will need to understand git before you can use it effectively.
  • The first checkout takes a lot longer compared to Subversion, because git gets the entire repository history. But this is something you only need to do only once. As a nice side effect, you will have a backup of the central repository. Should the central repository die a horrible death, it could be rebuilt from a git checkout.


Start a local repository and push it to a server later with Bazaar and Git

Once you get comfortable with distributed version control, this probably becomes a habit: whenever you start hacking on something new you create a local repository right away, and only later on you push it to a server (for backup). With Bazaar you can even switch to a centralized workflow (the server becomes a master) at any time (and switch back).

With Bazaar

To push a local repository to a server, the bzr command must be installed and on the $PATH of the user.

cd /path/to/your/new/project
bzr init
bzr add
bzr commit -m 'first commit, added all files'
bzr push bzr+ssh://username@server/home/username/path/to/repos/bzr/project

Extra tips:

  • If the parent directories don’t exist on the  server, then use –create-prefix to create all parents
  • To switch to a centralized workflow where your local commits will be automatically pushed to the server do “bzr bind”, and to switch back do “bzr unbind”

With Git

To push a local repository to a server, the git command must be installed and on the $PATH of the user.

cd /path/to/your/new/project
git init
git add .
git commit -m 'first commit, added all files'
git clone --bare . project.git
rsync -a project.git username@server:path/to/repos/git/project.git
rm -fr project.git
git remote add origin username@server:path/to/repos/git/project.git

The step of pushing to the server is less intuitive in Git compared to Bazaar, but I am still new to Git so there might be a better more elegant way. (Please comment if you know!)

Share a folder read-only from Linux to Windows with Samba

I thought sharing a folder on Linux to Windows machines read-only and without any authentication whatsoever was very simple to do with Samba. And it really is, if you know Samba well 🙂 Which I don’t, so I had some troubles due to incorrect value for the “security” option. The default value in a relatively modern installation is “user”, with other possible values like “share” marked as deprecated in the config file. Because of that small mistake my sanity tests failed with error messages like:

C:>net view \servername
 System error 5 has occurred.

The network path was not found.


C:>dir \servernamesharename
 Logon failure: unknown user name or bad password.

Changing “security = user” to “security = share” was the fix. And it is well explained in “man smb.conf”.

Btw the “testparm -s” command shows settings that override the default values, which can be pretty handy in debugging your setup.

UPDATE: you probably also want samba to start on system boot. In redhat derivatives you can do that with:

chkconfig smb on

Useful links to debug Samba (if you are in a hurry)

A nice series of articles for doing a more sophisticated setup the right way


StatSVN is a fine tool for Subversion history statistics

StatSVN is easy to use and free, and can reveal interesting statistics about the commit history of a Subversion repository.

One gotcha I had with it though is that occasionally it can have totally misleading error messages like this one:

svn log: svn info: XML document structures must start and end within the same entity.

The tool works with an XML file generated by “svn log -v –xml” and a svn checkout directory. Although this error message clearly suggests a broken XML file, it was nonsense in all the cases I’ve seen, and the real cause was problems with the svn checkout directory, for example because of files with “!” or “~” status. After I cleaned up the svn checkout directory, statsvn worked nicely.

Another tool for the same purpose that can be interesting is svnplot (a completely different tool, nothing to do with statsvn).


A few people asked what is the meaning of “svn status” showing files with “!” and “~” and how to clean them up. These are problems in your own working directory, most likely because you are using subversion incorrectly. Files marked with “!” are usually files that were deleted not with “svn rm”. A “svn update” can bring them back.

Directories marked with “~” usually happen if the “.svn” directory disappeared from that directory. One typical example is when people incorrectly add build output folders to their repository, and when they build the project the output folder is recreated, inevitably without the “.svn” control directories. The best solution is to remove the build products from the repository and do a clean checkout.

In general, the strange errors with svnstat mentioned in the post should not happen if you run statsvn right after a “svn checkout”.

Severed Fifth is totally awesome hard pounding metal, and that for free

Severed Fifth is a metal band (?), with so far two albums that are self-produced, self-released, written, performed and recorded by Jono Bacon, community manager of Ubuntu, author of the awesome (and free) book The Art of Community. I really didn’t expect much from a music made by just one guy, but man, this is totally awesome hard pounding metal! And the guy is releasing the albums completely for free (under Creative Commons Attribution ShareAlike license). That’s right, it’s just out there for everybody to enjoy, so if you like some good metal, listen to it at (my favourite is The Lake, when the heavy rhythmic pounding kicks in at about halfway)

Yes, this topic is right at home in a hacking journal 😉

Decentralized development workflow with Bazaar and DVCS in general

Many of my friends are getting into Bazaar or other distributed version control these days.

Bazaar is in the same class as git and mercurial = distributed version control software or DVCS. This class is significantly more powerful compared to traditional version control software (VCS) such as Subversion. The feature set of DVCS is often a superset of VCS, so usually you can do everything with DVCS that you could do with VCS, and a whole lot more.

The most significant consequence of being “distributed” is that a “checkout” is never “just a checkout”, it’s a whole repository, with full history.

There are two checkout commands in Bazaar, “checkout” and “branch”, for two different workflows.

You use “bzr checkout” for a centralized workflow, like the one used with Subversion. That is, there is a central repository that all developers commit to, they checkout the project with “bzr checkout”, and when they commit with “bzr commit” it gets written to the central repository. To merge the changes by other developers, you do “bzr update”. And when you commit, if other developers had commits while you were working, then you have to do “bzr update” first before you can do “bzr commit”. In this workflow bazaar works exactly the same way as Subversion, with the added benefits of having the entire history on your computer, so you can do diff and log without hitting the network.

You use “bzr branch” for a de-centralized workflow, radically different from Subversion. The repository you branched from is called the “parent” branch and is remembered for reference, but your local branch is not bound to it in any way. Practically it means that all your commits will be local only, to your local branch, and not to the parent. And since your local branch is its own master, “bzr update” will do nothing, because you are in fact always up to date 😉 To merge changes done by other developers in the parent, use “bzr rebase”. This will basically rewind your local branch to the revision that you branched from, replay the changes made by others in the parent, and finally replay your own changes. The same way as with “svn update” (or “bzr update”), conflicts may happen during this operation. After resolving conflicts, you can continue with “bzr rebase-continue”.

Side note: the “rebase” command is not a standard command in Bazaar, it is in the “rewrite” plugin. If you don’t have the plugin you can accomplish basically the same with “bzr merge”, but “bzr rebase” is a tad bit cleaner.

When your changes are ready to be merged into the parent branch, you push your branch to a place where your team can access it, and the manager of the parent branch can merge from it and commit into the parent branch. In the end, there is no practical difference between the “checkout” and “branch” workflows, the end result is the same. As such, with a DVCS there is little reason to use the “checkout” workflow.

Being disconnected from a central branch gives you a lot of freedom, for example you can create experimental branches of your own without affecting your team members, you can hack and commit even when you don’t have internet, and of course have the entire project history with you at all times. There is also no central repository server that may crash, no need to setup one, no need to manage user accounts and authentication. Backup is almost unnecessary, if you have enough developers in your team, somebody will always have a copy of the repository so you could lose a few latest revisions only. Once you get comfortable with a DVCS, you will find that the tool doesn’t get in your way, you can happily slice and dice repositories. Branching and merging of branches is straightforward and perfectly natural with any DVCS, there is none of the black magic Subversion needs to have that working.

You can read more about this and other variations of the decentralized workflow in the Bazaar documentation. I use mainly Bazaar for its intuitive simplicity, Git with Eclipse projects due to a lack of a good Bazaar plugin. The various DVCS certainly have some differences, but the essence is the same, and whichever you use, it will make you a happier developer with less stress.

Email forwarding option missing on newly setup google hosted domains

My internet hosting company has a nice feature to make it really easy to use Gmail for all my hosted domains. I’ve been using this for several domains, and I typically create an account and have it forward all incoming emails to my personal email account. Usually you do this in Mail settings / Forwarding and POP/IMAP but recently this option disappeared on the the google hosted domains, there is only POP/IMAP Download instead. Google Help pages are useless, there is nothing written about why the option is was removed.

But guess what, the feature is actually still there! You just have to wait! It seems there is a delay, and the email forwarding option is not available soon after you setup the domain. I don’t know why, I haven’t found relevant documentation. I just experienced with several domains already that I just need to wait a couple of days, and eventually the option appears.

You can tell it’s a bug, because if you try to create a filter, you will find a link “Manage your forwarding addresses” which takes you to the POP/IMAP Download page, where in fact it is impossible to setup forwarding addresses.

In short, it’s a gotcha. If you are experiencing this, give it a few days, hopefully the option will appear eventually.

Binaural Beats – hacking your own brain

I hesitated for a second whether this belongs to a journal of hacks. But hey, it’s actually hacking my own brain, so sure it is a hack!

Binaural beats are sound patterns that are supposed to induce brain activity, such as make you more productive or put you to sleep. Let’s keep it real, there is no scientific evidence that it actually works beyond a common placebo effect. But I tried it anyway. And… It works for me!

The free Binaural Beats application for iphone has several preset patterns. The “Busy thinking” preset with thunderstorm in the background seems to help me focus and work efficiently, especially in the morning. The “Pre-sleep induction” preset with ocean waves and seagulls in the background seem to help me sleep. The “Quick relaxation” preset with river trickling and birds chirping is also pleasant and helps working.

Is it just placebo effect? I don’t know, but it’s really pleasant. I might be getting addicted to the sounds. I recommend anyone to give it a try!

Using git with Eclipse 2

I’ve been using git with Eclipse for about a month now.

  • git svn rebase does not work in Eclipse gui. All the gui methods I tried say the repo is up to date, even though it’s not.
  • Synchronize workspace was very slow the few times I tried, so I don’t use it anymore.
  • Not sure yet how to work with maven sub-projects. It seems for all sub-projects I have to do “share project” to associate with git. Otherwise I don’t get the git actions in the Team menu of sub-projects.
About git on the command line, and in general…
  • Branch switching is nice and easy, quite fantastic actually.
  • I’m sure in speed benchmarks git will always beat all other VCS. In practice, I don’t notice a difference, at all.
  • git svn dcommit is nice, git will commit each commit one by one. Not sure bzr can do this so easily.
  • The git shell in windows is great! Since cygwin is not an option for me, the git bash shell is a fantastic alternative.
  • Browsing repository history is not nearly as easy and intuitive as bzr.
  • SHA as revision identifier is uncomfortable to use. I need to grab for the mouse all the time for copy-and-paste.
  • Before trying git the staging area looked the most attractive feature to me, with the ability to commit only hunks. In practice, I hardly ever want to commit specific hunks only, and it’s a bad practice anyway to commit untested code. Overall, having to stage every modification is not practical for me.

Overall, I really like git. I will use it when it’s the right tool for a job, but for now I will continue to use bzr for my personal (and admittedly light-weight) projects.