> I think the cost of dumping Clearcase is so high that no individual > project can afford to do it. So no one does. So you're stuck with it > forever. In practice, the issue of it being a sunk cost never enters the > discussion. "It's never too late to throw out all the code and start over." Prof. Michael Stonebraker (Mike's widely credited with making the worlds first successful relational database engine - the foundation of Ingres, Briton Lee and Oracle corporations RDBMSes, he founded Ingres, Illustra, and Cohera Corporations, was CTO of Informix for many years, etc, etc, etc.) > The problem is that Clearcase is integrated into your builds, into > developer scripts, into the release cycle and into fixing bugs in older > releases. Ripping all that out is extremely painful, and individual > project managers just don't see as a net win, quite reasonably in my > view. > > The only hope is a new project that shares no code with any other > existing project, and that, in my experience, is a rarity. When it comes to things which are intellectually resolved, and which have therefore become "a small matter of code," tractible solutions are usually available. Aside from the lack of vision, more often it's lack of courage to take steps to improve or a matter of the politics of blame which impede rational choice in the best interests of an organization. Following this logic, surely there are relatively easy ways out from the Awful Source Code Mangement System problem: Just don't. As just one of many possible strategies: Take a source dump of the trees you need to work with and make that a new day zero for those trees - more correctly, a new branch. Create an unencumbered build environment, staffed by a competent person or team, using your newly chosen source code management software. When other trees are recognized to be involved, either yank them from their ClearCase captivity or get ClearCase to give you diffs and integrate those as they occurr. I don't pretend to know all the issues, but for a coherent understanding of the _real_ challenge - which is completely non-technical - I recommend reading "The Prince" by Machiavelli - it's worth reading anyway. ...We, as developers, need to consider the impacts of our work on the larger domains of the companies which employ us. If too much energy is going into a broken infrastructural resource which is also key to the success of the venture, we need to help do something to resolve it. Consider that for a great many years the statistics on successful software projects have shown fully two thirds of all such projects fail outright and the current number must be much higher, pushed by the dot-com bubble and subsequent bursting. Do you want YOUR project or company to be among the debris? ...Yes, this is more a business question than a technical one but it's a decision that _must_ be informed by competent technical people like us in order to make the right choices. Good luck out there - your organizations survival just may depend on you. RT -- Richard Troy, Chief Scientist Science Tools Corporation rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/ _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
