Do you believe in God?

In advance, this paper is neither about God nor about his existence. I prefer to stay away from divine-related discussion, as belief in God is a personal issue.

However, I'm sure that whatever people can’t explain they put outside of human competency and ascribe it mystical attributes or halo of divinity. A good sample of this is lighting. Before Benjamin Franklin proved its electrical nature, it was thought to be a sign of God’s wrath. People often prefer myths, especially if those myths can compensate for their own lack of knowledge.

Recently I struggled with adding a new project under SVN control. Got failure to verify the sources added due violation of the requirements configured in pre-commit hook. It is unbelievable how painful might become the check in of couple dozens of files. Fairly possible, the process would be less terrible when files were not so huge and their upload takes an age, unfortunately, they were. Again and again I got the commit failure when did not provide certain properties requested by pre-commit hook. I did not specify svn:executable property for files "*.sh", the svn:mime-type for files "*.txt”, the svn:keywords... Certainly, it was greatest verification that I ever saw.

In theory, the requirements to be more verbal in comments looks quite reasonable. The idea there is to lead people properly describe what they are doing. It is, definitely, comme il faut in a team play and allow easily identify each commit beside other even for yourself. But, in practice, it is not work and might be easily cheated. For instance, the requirement to put at least 3 words per comment would force developer to be more verbal. However, I'm sure you've come across commits with comment sounds like: "Minor bug fixes". At least I had, and, certainly, very often. Such comments destroy the original idea, since they tell nothing. However, they have 3 words, consequently they will pass pre-hook checking. Could such kind of verification teach developer describe commit properly?

Let us leave the verbosity a while and look at svn:executable. According to SVN Red Book:

"... is used to control a versioned file's filesystem-level execute permission bit in a semi-automated way... This property has no effect on filesystems that have no concept of an executable permission bit, such as FAT32 and NTFS."

How often executable files might be needed immediately after they are checked out from SCM system? I do believe, not so much. Even if that file is not require the pre-processing (let’s say filtering and project properties substitution), it, quite often, requires a proper folder tree for normal execution. And I thought, to do so is the build system responsibility, is not it? On my mind, the svn:executable property has a doubtful sense, and I definitely sure that it is absolutely silly require it for files that has certain extension. So, where is sense to require it in pre-commit hook?

The similar story is about svn:mime-type. Even today it is clue for me why it was so important to set it to text/plain for “*.txt” files. In that case some of those files has checksum, so content was not mergeable at all, but the pre-commit hook do not allow commit them without that property. Where is the sense?

But, probably the best case was with svn:keywords. For whom who is not familiar with SVN, this property is useful when there is applied the property substitution on a project checkout. For instance, it could be version number, date of last update date or its owner and so on. Once “keyword” happened in file content, it will be substituted when file has been downloaded. But what if substitution is not used or, even, can damage sources be cause there is allowed content that can conflict with specified substitution?

Thus, returning to our sheep, what the bleep do we know? We have the comprehensive verification that is not effectively verified source and may be even dangerous as unified verification across all projects in the company. Moreover, so massive pre-hook checking might just turn your life into real hell on project check in. When I asked about this silly pre-hook I was simply told: "... it is common stuff ... " and was referred to "corporate rules". Holy crap! So our company has a profound interest in the execution bit of files to be committed? Or, perhaps, suppressing the contextual merging of “*.txt” files breaches some corporate law or other?

Here is another example. The Maven is used widely in our company. Recently we started using the Nexus to host the legion of mirrors of public and internal Maven’s repositories. Nexus serves the role of proxy, and, according to its name (nexus, [latin] the centre of something), could act as a central point for all repositories in a corporate intranet.

Imagine my surprise when I realized that the plan was for Nexus to proxy all repositories separately. In other words, it does not provide a central point! God sake, why it could not perform its primary purposes and do proxy all of them simultaneously? This would significantly reduce the size of any repository declarations inside POMs and / or user(s) settings. And it would reduce time that is spent on dependency resolving, especially for snapshot.

The insight came only recently when I noticed that the downloaded POM in local repository for an artifact in one our project was not the same as in remote repository. After lengthy investigation, I realized that there are two repositories and that each maintains two different artifacts but with the same groupId / artifactId. The first repository points to the usual artifact (i.e. a JAR) whereas the second points to a ZIP file. Obviously they have a different file names, but their POMs has the same, so only one could be stored locally. So the build may fail for totally unexpected reason.

It is clear that the people who configured Nexus failed to get it working as normal proxy, so they decide to keep everything as it was before. When I pointed out that there were two artifacts with the same POM, I was told that it did not matter because they were stored in different repositories. They really believed that it is rather Nexus bug, even beside fact that it just impossible to proxy two different things with the same identifier.

So, as in the past when people blame God or faith for their failure, today they refer on something beyond their responsibility: lack of time, corporate rules anything else but themselves. Everything is changing time, place… but not people. They are the same always.