On 15 June 2013 06:55, Dave Angel <da...@davea.name> wrote: > On 06/14/2013 10:24 AM, Grant Edwards wrote: > >> On 2013-06-14, Roy Smith <r...@panix.com> wrote: >> >> All that being said, it is, as Anssi points out, a horrible, bloated, >>> overpriced, complicated mess which requires teams of specially >>> trained ClearCase admins to run. In other words, it's exactly the >>> sort of thing big, stupid, Fortune-500 companies buy because the IBM >>> salesperson plays golf with the CIO. >>> >> >> Years ago, I worked at one largish company where a couple of the >> embedded development projects used ClearCase. The rest of us used CVS >> or RCS or some other cheap commercial systems. Judging by those >> results, ClearCase requires a full-time administrator for every 10 or >> so users. The other systems seemed to require almost no regular >> administration, and what was required was handled by the developers >> themselves (mayby a couple hours per month). The cost of ClearCase >> was also sky-high. >> >> > if I remember rightly, it was about two-thousand dollars per seat. And > the people I saw using it were using XCOPY to copy the stuff they needed > onto their local drives, then disabling the ClearCase service so they could > get some real work done. Compiles were about 10x slower with the service > active. >
I can absolutely confirm how much ClearCase slows things down. I completely refused to use dynamic views for several reasons - #1 being that if you lost your network connection you couldn't work at all, and #2 being how slow they were. Static views were slightly better as you could at least hijack files in that situation and keep working (and then be very very careful when you were back online). And then of course there was ClearCase Remote Client. I was working from home much of the time, so I got to use CCRC. It worked kinda well enough, and in that situation was much better than the native client. Don't ever ever try to use ClearCase native over a non-LAN connection. I can't stress this enough. The ClearCase protocol is unbelievably noisy, even if using static views. CCRC did have one major advantage over the native client though. I had the fun task when I moved my local team from CC to Mercurial of keeping the Mercurial and CC clients in sync. Turns out that CCRC was the best option, as I was able to parse its local state files and work out what timestamp ClearCase thought its files should be, set it appropriately from a Mercurial extension and convince CCRC that really, only these files have changed, not the thousand or so that just had their timestamp changed ... CCRC at least made that possible, even if it was a complete accident by the CCRC developers. Tim Delaney
-- http://mail.python.org/mailman/listinfo/python-list
