Category: source control

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:
-SVN
-Git
-Any other system