<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Reasons NOT to use ClearCase</title>
	<atom:link href="http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/</link>
	<description>Software Engineering: blog &#38; .lessons_learned</description>
	<lastBuildDate>Wed, 09 Jun 2010 08:18:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: monty</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-6260</link>
		<dc:creator>monty</dc:creator>
		<pubDate>Wed, 09 Jun 2010 08:18:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-6260</guid>
		<description>@SayNoToClearCase,

          You have no idea what everyone talking abt. please take some rest</description>
		<content:encoded><![CDATA[<p>@SayNoToClearCase,</p>
<p>          You have no idea what everyone talking abt. please take some rest</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicam Energy</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-6114</link>
		<dc:creator>Nicam Energy</dc:creator>
		<pubDate>Sat, 17 Apr 2010 22:39:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-6114</guid>
		<description>@SayNoToClearCase, I have a question for you.


Have you re-read the post before you submitted it?


You are a living contradiction my friend

.</description>
		<content:encoded><![CDATA[<p>@SayNoToClearCase, I have a question for you.</p>
<p>Have you re-read the post before you submitted it?</p>
<p>You are a living contradiction my friend</p>
<p>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicam Energy</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-6113</link>
		<dc:creator>Nicam Energy</dc:creator>
		<pubDate>Sat, 17 Apr 2010 22:35:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-6113</guid>
		<description>I have learned that these negative posts are submitted by incompetent and troubled  people, both developers and administrators.

I give you on piece of real example.

I have just started a new job in the city, the organization is using ClearCase.

You have no idea of the disgusting job the person that left has done. 

Do no take it to the tool, kick in the arse those incompetent pricks.

You know the most ridicule fact? They paid that Muppet more than me.</description>
		<content:encoded><![CDATA[<p>I have learned that these negative posts are submitted by incompetent and troubled  people, both developers and administrators.</p>
<p>I give you on piece of real example.</p>
<p>I have just started a new job in the city, the organization is using ClearCase.</p>
<p>You have no idea of the disgusting job the person that left has done. </p>
<p>Do no take it to the tool, kick in the arse those incompetent pricks.</p>
<p>You know the most ridicule fact? They paid that Muppet more than me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SayNoToClearCase</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-5600</link>
		<dc:creator>SayNoToClearCase</dc:creator>
		<pubDate>Thu, 28 Jan 2010 16:37:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-5600</guid>
		<description>The ability for developers to define ANY config specification in their development environment allows a dangerous form of mixing/matching branches/tags/timestamps of files in a view.

In a team of multiple developers, this results in the game &quot;Who Has The Real Config Spec Defining The Tip Of Development&quot;. Developers WILL try to workaround the merging/tagging system in source control to grab code from here, there, and everywhere in the repository by tailoring their config specs.

If you can&#039;t define what the actual tip of development is, then you have no releasable product. No releasable product means may well induce contractual penalties when the related project misses its delivery dates. I&#039;ve seen this situation nearly cost past employers millions in undelivered projects due to the ass-clownery that results.

This kind of obstacle also makes an excellent political game of &quot;eliminate the developers and manager from the non-delivering project&quot;.

Avoid jobs that require the use of ClearCase: it may just save you being laid off due to the ensuing politics.

SayNoToClearCase</description>
		<content:encoded><![CDATA[<p>The ability for developers to define ANY config specification in their development environment allows a dangerous form of mixing/matching branches/tags/timestamps of files in a view.</p>
<p>In a team of multiple developers, this results in the game &#8220;Who Has The Real Config Spec Defining The Tip Of Development&#8221;. Developers WILL try to workaround the merging/tagging system in source control to grab code from here, there, and everywhere in the repository by tailoring their config specs.</p>
<p>If you can&#8217;t define what the actual tip of development is, then you have no releasable product. No releasable product means may well induce contractual penalties when the related project misses its delivery dates. I&#8217;ve seen this situation nearly cost past employers millions in undelivered projects due to the ass-clownery that results.</p>
<p>This kind of obstacle also makes an excellent political game of &#8220;eliminate the developers and manager from the non-delivering project&#8221;.</p>
<p>Avoid jobs that require the use of ClearCase: it may just save you being laid off due to the ensuing politics.</p>
<p>SayNoToClearCase</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arbeitsverhinderungstool ClearCase : Zustandsforschung</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-3671</link>
		<dc:creator>Arbeitsverhinderungstool ClearCase : Zustandsforschung</dc:creator>
		<pubDate>Thu, 09 Jul 2009 09:48:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-3671</guid>
		<description>[...] Features von ClearCase kann man in den beiden Artikeln ClearCase, making easy things hard und Reasons NOT to use ClearCase [...]</description>
		<content:encoded><![CDATA[<p>[...] Features von ClearCase kann man in den beiden Artikeln ClearCase, making easy things hard und Reasons NOT to use ClearCase [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Garen</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-2680</link>
		<dc:creator>Garen</dc:creator>
		<pubDate>Thu, 28 May 2009 19:00:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-2680</guid>
		<description>clearfsimport has been around for a long time and be used to import a lot of files into CC, although it&#039;s not built into a context menu in CC Explorer.  It is now in CCRC though.

Never had any big complaints with CC performance.  If the project was large, simply used snapshot views.

Config-specs are a usability problem, and without atomic commits it&#039;s hard to implement CI, which is my main complaint with CC.

And if I was going to use one of the new DVCS systems, I&#039;d use Mercurial--which actually _works_ on platforms other than Linux. I don&#039;t really care if git can run in 0.01 seconds rather than 0.1 for an operation I do once an hour.</description>
		<content:encoded><![CDATA[<p>clearfsimport has been around for a long time and be used to import a lot of files into CC, although it&#8217;s not built into a context menu in CC Explorer.  It is now in CCRC though.</p>
<p>Never had any big complaints with CC performance.  If the project was large, simply used snapshot views.</p>
<p>Config-specs are a usability problem, and without atomic commits it&#8217;s hard to implement CI, which is my main complaint with CC.</p>
<p>And if I was going to use one of the new DVCS systems, I&#8217;d use Mercurial&#8211;which actually _works_ on platforms other than Linux. I don&#8217;t really care if git can run in 0.01 seconds rather than 0.1 for an operation I do once an hour.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-1158</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Wed, 25 Mar 2009 00:51:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-1158</guid>
		<description>I like atomic commits on every checkin, because then rollback of work tasks is much easier. Especially when doing refactorings I do lots of iterations and need this rollback of code states often.

Snapshot view is &quot;more&quot; offline as dynamic view. But still you need to be connected for checkout, when you&#039;re working on files. Hijack for me is not an option, because I want to use the version control locally and track my changes. With distributed scm-tools you can work completely offline with all the usual scm-features. Here you work on your &quot;personal&quot; branch for your work tasks and then merge to the public.

Lucky you that you never had performance issues with CC. But I guess that it is far from trivial to tune it properly in a distributed environment (most of the problems seems to come that its protocol sits on top of network shared drives). Other scm online-environments (e.g. subversion over WebDAV) tend to handle things much better. No matter where I downloaded subversion sources over the world from it was quite quick. I don&#039;t want to know how it would have performed when these projects used CC... 

You&#039;re right that the branching/merging features of CC are showstoppers on most projects. That is why you should not use CVS and subversion, where merging can be a big pain (especially if you move nodes around). Therefore I am looking to Git these days, from talks and articles it solves most of the shortcomings of CC and offers good branching/merging features. It also has been proven for big codebases. It is used for linux kernel (which is &gt;10MLOC) and many open source projects which are fed up with subversion adopt it.</description>
		<content:encoded><![CDATA[<p>I like atomic commits on every checkin, because then rollback of work tasks is much easier. Especially when doing refactorings I do lots of iterations and need this rollback of code states often.</p>
<p>Snapshot view is &#8220;more&#8221; offline as dynamic view. But still you need to be connected for checkout, when you&#8217;re working on files. Hijack for me is not an option, because I want to use the version control locally and track my changes. With distributed scm-tools you can work completely offline with all the usual scm-features. Here you work on your &#8220;personal&#8221; branch for your work tasks and then merge to the public.</p>
<p>Lucky you that you never had performance issues with CC. But I guess that it is far from trivial to tune it properly in a distributed environment (most of the problems seems to come that its protocol sits on top of network shared drives). Other scm online-environments (e.g. subversion over WebDAV) tend to handle things much better. No matter where I downloaded subversion sources over the world from it was quite quick. I don&#8217;t want to know how it would have performed when these projects used CC&#8230; </p>
<p>You&#8217;re right that the branching/merging features of CC are showstoppers on most projects. That is why you should not use CVS and subversion, where merging can be a big pain (especially if you move nodes around). Therefore I am looking to Git these days, from talks and articles it solves most of the shortcomings of CC and offers good branching/merging features. It also has been proven for big codebases. It is used for linux kernel (which is >10MLOC) and many open source projects which are fed up with subversion adopt it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: McHalls</title>
		<link>http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/comment-page-1/#comment-1086</link>
		<dc:creator>McHalls</dc:creator>
		<pubDate>Fri, 20 Mar 2009 20:57:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.aldana-online.de/?p=128#comment-1086</guid>
		<description>I am not a CC fan, but u stated some not fair reasons.

No atomic commits
True, no support for that. However, in most cases you dont even need that. When u merge from branches, even without labeling u can be on the safe side and rollback to a previous state.

Crappy user interface
Depends on taste of course. Recursive checkin in fact exists, but its not that simple as it should be, I agree. Of course u have CLI on native windows too, u dont need cygwin for that.

High administration efforts
I agree, though its usually 1 person is enough even for larger projects.

Horrible performance
Interesting, the volume of slowlyness u mention, I never crossed. Usually its fast enough not to even recognize the chechout/checkin. If its configured properly, u should see no such bad performance.

Lack of support of distributed development
Well, snapshot view is your friend if u need offline work. Honestly, what do u expect from a tool, when u r offline?

U say its bad that hijacking simply takes off the readonly flag, but u should be happy about that. Its simple, u dont even need CC to do that an it works. 

Imagine u have a local repo and u do checkins and a lot of stuff - what do you exactly gain having the repo locally? U need to merge in the end and thats what CC is doing and thats what other tools do too. U have no choice.

Again, not a CC fan, but other tools are sooo lame in GUI interfaces and especially in merging, that they are simply not suitable for larger projects. No wonder that larger companies use commercial tools. If there would be an open source alternative that would be even close to what CC offers, CC would lose a lot of customer. But there IS a reason why it is used in so many places.

Also dont forget that CC customization is possible and CC is not only a version handler tool. Others are.</description>
		<content:encoded><![CDATA[<p>I am not a CC fan, but u stated some not fair reasons.</p>
<p>No atomic commits<br />
True, no support for that. However, in most cases you dont even need that. When u merge from branches, even without labeling u can be on the safe side and rollback to a previous state.</p>
<p>Crappy user interface<br />
Depends on taste of course. Recursive checkin in fact exists, but its not that simple as it should be, I agree. Of course u have CLI on native windows too, u dont need cygwin for that.</p>
<p>High administration efforts<br />
I agree, though its usually 1 person is enough even for larger projects.</p>
<p>Horrible performance<br />
Interesting, the volume of slowlyness u mention, I never crossed. Usually its fast enough not to even recognize the chechout/checkin. If its configured properly, u should see no such bad performance.</p>
<p>Lack of support of distributed development<br />
Well, snapshot view is your friend if u need offline work. Honestly, what do u expect from a tool, when u r offline?</p>
<p>U say its bad that hijacking simply takes off the readonly flag, but u should be happy about that. Its simple, u dont even need CC to do that an it works. </p>
<p>Imagine u have a local repo and u do checkins and a lot of stuff &#8211; what do you exactly gain having the repo locally? U need to merge in the end and thats what CC is doing and thats what other tools do too. U have no choice.</p>
<p>Again, not a CC fan, but other tools are sooo lame in GUI interfaces and especially in merging, that they are simply not suitable for larger projects. No wonder that larger companies use commercial tools. If there would be an open source alternative that would be even close to what CC offers, CC would lose a lot of customer. But there IS a reason why it is used in so many places.</p>
<p>Also dont forget that CC customization is possible and CC is not only a version handler tool. Others are.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
