Strange problems with git-svn fatal: "Cannot open '.git/wJj4wQYBct': Permission denied hash-object -w --stdin-paths --no-filters: command returned error: 128"

While trying to convert an internal Subversion repository with git-svn I ran into the same error over and over again. After a lot of successful revision conversions, I always got:

fatal: "Cannot open '.git/wJj4wQYBct': Permission denied
hash-object -w --stdin-paths --no-filters: command returned error: 128"

After searching the web (the usual suspects http://stackoverflow.com/ and Google) and trying a lot of the given hints, I finally tried to checkout the trunk of the repository with subversion directly and did not succeed as well.
Now I firstly was even thinking our subversion repository might be corrupt until a sudden insight grew in me: while I really like the Macbook Pro given to me by the company, the Avira virus scanner was detecting the EICAR test virus in the test suite, this showed up in the quarantine logs!
Now the rest was a piece of cake: by applying the hints on the Avira KB for excluding specific paths I finally succeeded by excluding only this specific directory where the conversion took place.

Using maven-release-plugin and maven-scm-plugin to tag all submodules of a multimodule project

I just created a sample multi module maven project in which by using the maven-release-plugin and the maven-scm-plugin I achieved my goal to create additional tags for the module artifacts as well. For a rationale see the included README.

There are two branches, one working with git and one with Subversion (in the master branch).

Storing your OpenOffice, Xmind, ... zippy documents more efficiently in a SCM

I really like having my sourcecode and documents in a SCM since I first discovered CVS about 14 years back and introduced it in two companies thereafter, one of which had tried to use VSS (not really usable at the time, you had to lock files for editing which made you call for the VSS admin when your colleague was not available and did not allow to work on the same document at all), while in the other developers only had been using timestamped ZIP files before, which made team work really hard. In my current company I (maybe) made a mistake by pushing the switch from CVS to SVN about five years ago.
Back then I took a look at one of the first DVCS systems (arch) but found it to be to confusing (at least for me, YMMV). About three years ago I discovered Mercurial and really have liked it since, especially as I really like Python. I tried Bazaar as well because it promised better integration with Subversion but it used several different, incompatible repository formats so I had problems even checking out a remote repository more than once and the speed was not at all convincing as well. Nowadays I use Git sometimes which I like as well and I am especially impressed by the simple underlaying concept of storing things. However I still feel more comfortable with Mercurial right now and use Bitbucket a lot.
After having used DVCS you feel almost crippled by SVNs bad merging support and the idea of having no distinction between branches and tags seems not so clever anymore, we have had some hard times using standard SVN tools after a decision to put release tags in a directory called releases and are sometimes still struggling to find a common point of view on the correct position of trunk and what to store beneath release tags in repositories used by more than one project, so they are unambiguous both for our tooling chain and understandable for humans.
Well, back to the topic: nowadays a lot of software uses ZIP containers to store their information, which will bloat your SCMs because every new zip is so different from it's ancestor, even if you did only include a single new word, because the compression and a preview picture will make the new version very different from the old one. So I wrote a little Python script which will uncompress, delete the included preview and put the remaining files back into an uncompressed ZIP again using the stored method.

Triggering Hudson builds with Mercurial hooks - a variation

Ashlux writes about triggering Hudson builds with Mercurial hooks on his blog. The basic hook described is:

[hooks]
changegroup.hudson = curl http://hudson_url/job/project_name/build?delay=0sec

I use this technique as well a lot with two refinements:

1. I use polling instead of build. So the url is http://hudson_url/job/project_name/polling. This will poll your Mercurial repository and only if something really changed, the build will be triggered.
2. Instead of setting up authentication I always use the TOKEN approach described on Remote access API, so the url gets http://hudson_url/job/project_name/polling?token=TOKEN

Using tokens you do not need to submit any authentication information. Bitbucket offers a POST service which you may use instead of the aforementioned hook. Github offers a similar service.