ClearCase label issue

Some people prefer ClearCase, but this is probably due to a lack of understanding how ClearCase works. I herewith summarize some issues I had with ClearCase:
– Renaming a file, renames the file in all historical versions of the file…. you better take a copy of your ClearCase VOB before thinking about renaming.
– Labeling a file, and moving the previous label. There is no clue where the previous label was, nor who did it. You better take a daily archive of your complete structure as a back-up (and store this archive on a real system).
– Fixing the read-only mark of a file. You like the file getting orphaned or eclipsed…. this is a good start.
– Adding a file to a folder in two different development tracks. Good luck, you will be tempted to believe that your file should be present in all environments, versions, …
– Creating a version of a folder where there are active check-outs, well, they will be included in all versions of a file.
– Finding out if there are files check-out, not in ClearCase, … or whatever in +200 folders… Good luck, I suggest you move to a unix environment first, and write some script.
– Changing the casing of a file. Good luck, it just crashes your Vob, your client, your view, … You can try again but it will fail always. But you know, you can keep 2 versions in the Vob of the same file, if your casing is different.
Label a set of files at a certain moment in the future. Impossible without advance scripting.

The Cause:
Because ClearCase mounts VOBs the same way for all platforms, and tries to resemble a FAT file system, it just does use the lowest denominator of all, and uses the read-only mark of a file to act upon. (At least SVN stores this information in another place.)
Because ClearCase does not support group-commit. It cannot handle the directory at the same moment it handles the file.
Because ClearCase is evil.

The Solution:
-Any other system

Make for build automation

Here you will find a nice description of Make.

If you want to do building automation with make, please make sure to read through it. Alternatively, one could use other tools such as Ant or select one of this list.

It is a tough choice, and each of them has its advantages and disadvantages. As long as the source code is kept in a controlled environment, you have a stable base to start with….

Source control statistics

People are using following systems:

CVS 12,6%
Git/GitHub 6,8%
IBM Rational ClearCase 2,8%
IBM Rational Team Concert 0,9%
IBM Rational Telelogic Synergy Suite 0,2%
Mercurial 3,0%
Microsoft Team Foundation Server 0,8%
Microsoft Visual SourceSafe 1,6%
Perforce 3,0%
Subversion 58,3%
None – I don’t use a source code management system 5,6%
Don’t know 1,4%
Other (specify) 2,9%

Source: Eclipse Community Survey 2010

Deploy svn on your server

SVN deployments are not always easy and straightforward. I prefer to have a web-interface such as WebSVN that will allow you to see the source code and check differences in between versions from a simple web-client. This is fine for reading, but not useful for getting a working copy to your local machine.

For downloading the source-tree, the branches or trunk, one would use one of the access protocols. The most straightforward is HTTP. This is understood by everyone and allows a simple viewer even without WebSVN. For commits, we would use ideally HTTPS. Both protocols require the WebDAV protocol to be deployed.

If you are working on a local machine, or in a local Unix/Linux/Mac environment, one would choose SVN or SVN+SSH. Given the difficulty of setting up SSH in a corporate environment from a Windows machine, I do not believe this is a real option for a vast majority of users. (Yes, some developers are living in a Windows corporate world.)

Lets assume the following scenario. Developer is somewhere on the internet, the repository is in corporate walls and a firewall is sitting in between. The correct set-up would be. HTTPS on the developer’s pc, connect to proxy forwarder gateway at corporate DMZ, forward this to in-house HTTPS WebDAV enabled SVN server.

The trouble with this set-up is that while the developer can browse the repository over HTTPS (or HTTP) or by means of the WebSVN directory, he cannot check-in if his pc is located behind a Microsoft proxy server…

Error getting OPTIONS – error 503, or MKACTIVITY – error 503.

I am still looking into a resolution for this problem. Any help welcome….