Tom Buskey <t...@buskey.name> writes: > > Our developers want to switch, management doesn't :-/ so we'll probably have > it around forever. > > I generally don't like it because it's a kernel mod and generates a high I/O > load.
Yes. When I was using it (a couple of years ago), there were also some other things that were irritating, but the way it just slowed down my build/test cycle drove me crazy. I figured it was due to some combination of I/O and the (overloaded) server having to continuously sort out whatever internal locks were necessary to manage that sort of system. When I figured out how to get things out of ClearCase, edit/build/test on a local disk, and then commit back into ClearCase, I was impressed by the speed-difference--I literally had *hours* of extra time per week. YMMV based on the size/shape/speed of your server/network/project. > What do people switch to? > > ClearCase provides a central repository and there's some protection against > shooting yourself in the foot. Plus there's integration with ClearQuest. > We are not able to get training in developer tools and our users do not check > in (1-3 years) often. That's awefully similar to my experience. A number of people with whom I worked using ClearCase also would routinely avoid committing changes to the repository for months or years. This would semi-regularly impact other developers, who would often find workarounds. I took this as being, at least in part, a symptom of ClearCase--and I think it got better after we moved away from ClearCase to things more usable. *I* certainly was more apt to check my changes back in when I was working with other version-control systems. > I think something designed for multiple repositories and lots of > checkins (GIT) wouldn't be a good fit, but I'm not a developer ;-) That was actually my initial workaround: I had to decouple our build-system from ClearCase (when I got there, it wasn't possible to build a copy of the code residing anywhere outside of the ClearCase mount), and then I just created DVCS repositories inside ClearCase, and wrote a couple of scripts to sync changes between ClearCase and the DVCS repositories. So, I ended up with something that effectively let me use ClearCase more `like CVS or Subversion': I could check out from ClearCase into a local working copy, make my changes, build, test, and then check the changes back into ClearCase. I was using Bazaar, but git would presumably work just as well it it's better suited to the users in question. Later I managed to convince everyone else to just migrade away from ClearCase; Subversion turned out to be the common intermediate format for migrating away from proprietary version-control system, and I found a mostly-working Perl script that could convert from ClearCase to Subversion; I wasn't entirely satisfied with the output (commits came out in topological rather than chronological order), but I just had to write a couple of shell scripts to pull the svn repository apart and put it back together in the right order. Once you get into Subversion, you can pretty easily convert from that to any of the more modern tools. Or, if you like Subversion, you can just stay there. > On Thu, Jul 11, 2013 at 2:45 PM, Joshua Judson Rosen <roz...@geekspace.com> > wrote: > > Tom Buskey <t...@buskey.name> writes: > > > > We use ClearCase here and[...] > > Sorry to hear that. > > I have some experience both working around ClearCase and migrating off > of it, if you are (or anyone else is) interested. > > -- > "'tis an ill wind that blows no minds." > -- "'tis an ill wind that blows no minds." _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
