3 ms·

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or a

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit a fair amount also. Plus, emacs is awsome :-P [1] https://en.m.wikipedia.org/wiki/Rational_ClearCase https://en.m.wikipedia.org/wiki/Rational_ClearCase [2] https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility

celeritascelery 8y ago
I never really understood git until I used magit
sepen77 8y ago
No, it has not improved. I last used it around a year ago at a company where a lot of young engineers had to pick up a 20 year old code base. Suffice to say, the expertise for ClearCase really wasn't there and it was an absolute mess.
kruczek 8y ago
I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow. First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally write that configuration file in such a way that you'll have half of repository checked out from one version of code, while the other half is checked out from another version of code. Then there is history of changes. Or in case of ClearCase: histories of changes. Because there are many, in fact as many as there are files. Yes, each file has its own history of changes, completely independent from other files. So if you make a commit which changes 10 files, CC will create separate commit for each of those 10 files, each with the same commit message. Needless to say, browsing history with same commit messages repeated tens or hundred of times, is quite an adventure. Oh, and because of that, it is not possible to simply checkout some old version of code. If you are lucky, you will have put labels on all files of needed version of code, so then you can checkout that label. Otherwise the only option is to checkout based on dates of commits, and hope that your provided date won't actually cut any commit in half.
- adrianN 8y ago
  The model is fairly similar to CVS, which also keeps histories of files instead of a history of the repository. The ability to have half of your repository come from one "branch" and the other half from a different branch is actually seen as a feature. This enables workflows similar to what you can do with submodules in git. Having to manage your config specs and the inability to go back to old versions of your software (or in fact just have something reproducible for your build servers) unless you meticulously label everything makes Clearcase of course barely useable. It gets extra interesting if you use multi-site Clearcase and your replicas stop synching.
  - bdavis__ 8y ago
    You have to label (tag) every change or it would be impossible.
jnurmine 8y ago
Once upon a time, I remember having to use Visual Sourcesafe, and it started silently corrupting the repository after 2 Gb. Probably some length somewhere was a 32-bit signed variable. I remember that the corruption was silent. That was bad. But nowhere as bad as Clearcase was in general. Clearcase is like the bastard child of a barrel of horseshit and a mountain of self-inflicted hurt. One had to use "views" of which there were two types, and some kind of special mount point where the view loaded things from a source repository, given a "config specification" which defined from which versions (branches?) files should be loaded. Making a branch took a huge amount of time for a non-trivial source repository. It was "take a coffee" long time. Sometimes the views went bad. I don't luckily even remember all the problems, this was over 10 years ago. The config specs seemed somehow to defy logic. Something always broke with them. Usually one just copied premade config specs made by someone with a transcended mind who seemed to have somehow figured out the underlying logic. And... I can't just put to words how bad Clearcase was (is?). That is my experience with it, and I will without a doubt choose Git over VSS, SVN, CVS, RCS, Clearcase and whatnot any day.
- dustfinger 8y ago
  LOL - so funny. By the way, I also have experienced Visual Source Safe silent corruption -- horrible!
bdavis__ 8y ago
it has not been improved or even updated in but minimal ways. i am surprised you did not experience the intellectual delight of using the ClearCase 'config spec' with it's ability to use rules to extract the source baseline you wish to work with. In all seriousness, it is very flexible and allows significant innovation in baseline management. In 1995, it was state of the art and revolutionary. Today a bit clunky and off the mainstream. Compared to CVS it was a very sophisticated tool. The 'visual tree view' it provides is still very good, even today. (note: i don't really like it and will not mind changing to a different system sometime this century)
tedmiston 8y ago
ClearCase was my first VCS and I couldn't agree more. Compared to that nearly everything with git is easy and few things aside from complex merge conflicts / unstashing conflicts are difficult.

celeritascelery 8y ago

I never really understood git until I used magit

sepen77 8y ago

No, it has not improved. I last used it around a year ago at a company where a lot of young engineers had to pick up a 20 year old code base. Suffice to say, the expertise for ClearCase really wasn't there and it was an absolute mess.

kruczek 8y ago

I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow. First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally write that configuration file in such a way that you'll have half of repository checked out from one version of code, while the other half is checked out from another version of code. Then there is history of changes. Or in case of ClearCase: histories of changes. Because there are many, in fact as many as there are files. Yes, each file has its own history of changes, completely independent from other files. So if you make a commit which changes 10 files, CC will create separate commit for each of those 10 files, each with the same commit message. Needless to say, browsing history with same commit messages repeated tens or hundred of times, is quite an adventure. Oh, and because of that, it is not possible to simply checkout some old version of code. If you are lucky, you will have put labels on all files of needed version of code, so then you can checkout that label. Otherwise the only option is to checkout based on dates of commits, and hope that your provided date won't actually cut any commit in half.

adrianN 8y ago
The model is fairly similar to CVS, which also keeps histories of files instead of a history of the repository. The ability to have half of your repository come from one "branch" and the other half from a different branch is actually seen as a feature. This enables workflows similar to what you can do with submodules in git. Having to manage your config specs and the inability to go back to old versions of your software (or in fact just have something reproducible for your build servers) unless you meticulously label everything makes Clearcase of course barely useable. It gets extra interesting if you use multi-site Clearcase and your replicas stop synching.
- bdavis__ 8y ago
  You have to label (tag) every change or it would be impossible.

jnurmine 8y ago

Once upon a time, I remember having to use Visual Sourcesafe, and it started silently corrupting the repository after 2 Gb. Probably some length somewhere was a 32-bit signed variable. I remember that the corruption was silent. That was bad. But nowhere as bad as Clearcase was in general. Clearcase is like the bastard child of a barrel of horseshit and a mountain of self-inflicted hurt. One had to use "views" of which there were two types, and some kind of special mount point where the view loaded things from a source repository, given a "config specification" which defined from which versions (branches?) files should be loaded. Making a branch took a huge amount of time for a non-trivial source repository. It was "take a coffee" long time. Sometimes the views went bad. I don't luckily even remember all the problems, this was over 10 years ago. The config specs seemed somehow to defy logic. Something always broke with them. Usually one just copied premade config specs made by someone with a transcended mind who seemed to have somehow figured out the underlying logic. And... I can't just put to words how bad Clearcase was (is?). That is my experience with it, and I will without a doubt choose Git over VSS, SVN, CVS, RCS, Clearcase and whatnot any day.

dustfinger 8y ago
LOL - so funny. By the way, I also have experienced Visual Source Safe silent corruption -- horrible!

bdavis__ 8y ago

it has not been improved or even updated in but minimal ways. i am surprised you did not experience the intellectual delight of using the ClearCase 'config spec' with it's ability to use rules to extract the source baseline you wish to work with. In all seriousness, it is very flexible and allows significant innovation in baseline management. In 1995, it was state of the art and revolutionary. Today a bit clunky and off the mainstream. Compared to CVS it was a very sophisticated tool. The 'visual tree view' it provides is still very good, even today. (note: i don't really like it and will not mind changing to a different system sometime this century)

tedmiston 8y ago

ClearCase was my first VCS and I couldn't agree more. Compared to that nearly everything with git is easy and few things aside from complex merge conflicts / unstashing conflicts are difficult.