The case of the curious commit message
chrisoldwood.blogspot.com
chrisoldwood.blogspot.com
The need to "check out" a file, first, became rapidly infuriating. People would deal with it by simply leaving their files unlocked (using a shell script). "Checking out" a file would simply nudge the filesystem lock, as long as the server had not detected a change. In the case there was no change, the programmer could make changes, "check out" the file, just before checking it back in, and the server would get the change. If the server had detected a change, however (it did not use checksums, like Git. The server had a transaction database that it consulted), it would overwrite the file on the programmer's workstation, before "unlocking" it.
As you can imagine, this allowed me to vastly improve my vocabulary of swear words, in several languages.
BG (Before Git) was a dark time, indeed.
The post says "On the plus side this got people discussing what a good commit message looked like". For git commit messages, and making them easy, it turns out a git commit template can help teammates ramp up:
The best feature of ClearCase is that with mvfs you can clone the repo in seconds since it's a virtual filesystem. A small database records your changes, and functions as a sort of overlay on top of the version you've "checked out".
ClearQuest was nice in that you can write your own SQL select queries to create bug lists. I don't remember if you could write DB-specific stuff (Oracle in our case) or if it had to be ODBC compliant. Unfortunately everything else about it kinda sucks.
Email was checked with enough frequency that it was commonly used for what we use SMS / text-messaging for today. You didn't really expect people to be near their landline phone, but you could connect with most students on campus pretty easily/rapidly with the e-mail system.
This is an era before there was cell-phone service on campus, but cell phones were still very rare anyway.