Arbeitsverhinderungstool ClearCase
von Benedikt
In meinem neuen Projekt ist die Maßgabe mit IBM Rational ClearCase zu arbeiten. Eigentlich ist ClearCase ein Tool zur Versionsverwaltung ähnlich wie CVS oder Subversion – allerdings kein gutes. ClearCase hält einen verdienten Platz 4 bei dreckstool.de für Entwicklungswerkzeuge.
Abgesehen davon dass das Team ein Produkt verwenden soll, von dem es keine Ahnung hat, ist ClearCase selbst ziemlicher Schrott.
Ein kleines Beispiel: Um eine Datei zu löschen, reicht es nicht das File zu löschen und einzuchecken. Man muss zunächst zusätzlich zur Datei den übergeordneten Ordner auschecken, dann kann man die Datei erst löschen und dann am Ende alles zusammen wieder einchecken.
Ein weiteres interessantes Thema: Die dynamischen Views, für die ClearCase so berühmt ist. Schade nur, dass wir feststellen mussten, dass ein Build auf der dynamischen View bei uns so zwischen 15 und 30 Minuten dauert – hat man die Files lokal, dann ist das eine Sache von ungefähr einer Minute. Daher pfeifen wir jetzt auf dynamische Views und arbeiten mit Snapshot-Views.
Auch lustig: Es gibt keine Möglichkeit, Dateien von der Versionskontrolle auszuschließen. Also sowas wie die ignore-Funktionalität bei CVS oder SVN. Eine absolute Notwendigkeit, um vernünftig arbeiten zu können. Geht bei ClearCase einfach nicht. Resultat: Wir haben bereits nach 2 Wochen ein lustiges Durcheinander an Dateien im Repository, die dort nie hätten rein sollen.
Noch mehr über die interessanten Features von ClearCase kann man in den beiden Artikeln ClearCase, making easy things hard und Reasons NOT to use ClearCase lesen.
Insgesamt bekommt man bei der Bedienung so ein bisschen den Eindruck, dass sich jemand wirklich viele Gedanken gemacht hat, wie er den Entwicklern die Arbeit mit dem Tool besonders schwer machen kann. Ich glaube ich habe in den letzten zwei Wochen die Hälfte der Zeit damit verbracht, mit ClearCase zu kämpfen und mit den Support zu telefonieren.
Ich bin schon sehr gespannt wieviel Zeit wir noch mit diesem Tool verlieren, das uns eigentlich die Arbeit hätte erleichtern sollen.
Kommentare
Hi Beni,
Wir verwenden es hier auch… Es ist ein wahres dreckstool.. und hässlich noch dazu! Das upgrade zur absoluten arbeitsblockade erhältst du im übrigen, wenn du das ganze noch mit clearquest kombinierst. Dann darfst du nämlich all deine aktivitäten noch mit einem projektplan synchronisieren, entsprechend verbuchen und kommentieren.
Schöne Grüße aus Kota Kinabalu
hmmm, ich sage einfach mal – Ihr habt einfach keine Ahnung wie man ClearCase zu benutzen habt. Es bietet so ziemlich alles was man fuer ein sicheres SCM Service benoetigt. Zugegeben – es ist komplex, aber richtig eingesetzt versetzt es einen in die Lage einen guten SCM Service aufzubauen. Bin fuer weitere Diskussionen gerne offen
Gruss
Uwe
Das Thema “keine Ahnung” mag sicherlich eine Rolle spielen. Der Punkt ist aber: Ich will keine Ahnung haben müssen. Ich bin das Arbeiten mit diversen anderen SCM-Tools gewohnt und da ist es eigentlich immer so, dass man direkt einsteigen kann und sich diese Tools transparent in die Arbeitsentwicklung integrieren. Bei ClearCase habe ich den Eindruck, dass man sich einfach zu viel um die Versionskontrolle kümmern muss. Ich will keinen SCM-Consultant brauchen müssen, um eine vernünftige Quellcode-Verwaltung zu haben.
So wie der Artikel hier geschrieben ist, scheint das Problem wieder mal vor dem Rechner zu sitzen. SCM ist ein komplexes Thema und ein Tool wie ClearCase kann dabei helfen das in den Griff zu bekommen, aber es gilt immer noch die Weisheit “A fool with a tool is still a tool”. In meinem Job mache ich immer wieder die Erfahrung, dass es bei der Einführung eines SCM-Tools mehr auf die richtige Ausgestaltung eines SCM-Prozesses ankommt. Dabei sind Fragen zu klären, wer darf wann, wo, was bearbeiten? Danach muss man das in der Technik des ausgewählten Tools umsetzen und dann, ganz wichtig, die Endanwender trainieren. Dann passieren auch nicht solche unwahrheiten wie “Man kann in ClearCase keine Dateien von der Versionskontrolle ausschliessen”. Das ist schlichtweg falsch. In ClearCase muss man im Gegenteil die Dateien wissentlich der Versionskontrolle hinzufügen, da zunächst erst einmal alles in dem view des Benutzers privat bleibt und nicht mit den anderen geteilt wird. Wenn da irgendein Automatismus agiert, dann kommt der von der IDE und dort kann man, z.B. im Eclipse sehr wohl eine ignore-List aufstellen, das ist dann aber Sache der IDE und des Benutzers der davor sitzt. Das andere Thema Dateien löschen. Der beschriebene Weg (Verzeichnis auschecken, Datei “löschen”, Verzeichnis einchecken) kommt daher, das ClearCase die Versionen und die Historie von Verzeichnissen und Dateien trennt. Das heisst um eine Datei zu verändern muss man nicht das Verzeichnis auschecken und umgekehrt um ein Verzeichnis in seiner Zusammensetzung zu modifizieren muss man nicht die Dateien auschecken. Wenn man das Konzept einmal verstanden hat, vor allen Dingen verstanden hat, dass die Datei als Element gar nicht gelöscht ist sondern der Name der Datei nur in der nächsten Version des Verzeichnisses nicht mehr auftaucht, dann weiss man es auch zu schätzen, dass man ganz einfach die Datei wieder herzaubern kann. Wenn dein Chef morgen ankommt und die Datei wieder haben will muss man dann einfach den Namen der Datei in der neuen Verzeichnisversion bekannt machen und voila, die Datei ist auf einmal wieder mit seiner gesamten Versionshistorie wieder da. Mach das mal mit einem anderen Tool….
Builds dauern in dynamischen Views länger? Welche denn? Java, C++? Je nachdem von welchen Builds wir sprechen kann man in ClearCase mit clearmake bereits schon gebaute Objekte wiederverwenden. Das erkennt dan ClearCase ganz automatisch. Bei einigen ClearCase-Usern werden dann builds in dynamischen Views auf einmal ganz schnell weil ClearCase dabei hilft die OBjekte zu bauen deren sourcen sich auch wirklich geändert haben.
So zum Abschluß: Jedes Tool braucht einen SCM-Administrator, auch ClearCase. Wenn jemand etwas anderes behauptet, dann ist das unseriös. Dann ist es die Aufgabe des SCM-Administrators genau die PRozesse und Eigenschaften des Tools zu implementieren die die Entwickler als Enduser brauchen. SCM sollte dem Enduser so wenig wie möglich an zusätzlicher Arbeit machen. Wenn das nicht so ist, dann muss der SCM-Admin vielleicht nochmal auf eine Schulung und den eingesetzten Prozess überarbeiten.