Benutzer:陰陽 阴阳/Rational ClearCase

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Überarbeitung[Bearbeiten | Quelltext bearbeiten]

Bitte verweise auf die Firma Rational. Beachte: Die Firma gehört nun IBM. Gruss, AFI 17:10, 22. Dez 2005 (CET)

Das steht ja mittlerweile im Artikel. Daher habe ich den Überarbeiten-Baustein entfernt. --jpp ?! 14:33, 15. Sep 2006 (CEST)
Aber der wiki-link fehlt -- 212.100.57.210 16:17, 2. Nov. 2006 (CET)

WTFs?[Bearbeiten | Quelltext bearbeiten]

Laut leuten die damit arbeiten soll das tool wohl in manchen bereichen ziemlich übel sein. Könnte einer mit erfahrung evtl. mal eine liste der probleme adden? Auch der enklische ertikel enthält viele nette daten die hier gut reinpassen würden. -- 212.100.57.210 16:17, 2. Nov. 2006 (CET)

Wir benutzen CC in einem mittelgroßen Projekt ( ca. 8 Leute programmieren seit ca 6 Jahren ) Ich schätze, die Benutzung von CC hat die Entwicklung um über 30 % verteuert. Grund ist die miserable Performance beim Lesen von Daten. Wir benutzen dynamic views. Das Benutzen von Snapshot views wurde getestet, leidet aber darunter, daß der dann nötige Abgleich mit dem Repository den Zeitgewinn bei der Entwicklung zunichte macht.

Omake hat auch seine Probleme: Es wird oft soviel Zeit verschwendet, zu überprüfen ob eine Zwischendatei wiederverwendet werden kann, als sie einfach neu zu kompilieren. Und das Linken dauert eine Ewigkeit.

Dabei ist der kompilierende Prozessor fast arbeitslos, weil meist auf Dateien aus dem Repository gewartet wird.

Weiterhin ist es nicht möglich, gleichzeitig Views auf verschiedene CC-Server offen zu haben, z.B. wenn man in mehreren Projekten beschäftigt ist. Es muss jeweils erst in der lokalen Registry umgestellt werden. D.h. kopieren oder Vereinigen von Daten aus mehreren Projekten ist sehr umständlich.

Zum Abschluss dauert die Nachtsicherung des CC-Repositorys bis zu 8 Stunden, es ist dann keine Arbeit mit dem Server möglich.

Der prinzipielle Fehler ist wohl, daß CC sich nicht auf das Dateisystem der Speichermediums stützt, sondern die Datei eines VOBs, auf die alle Benutzer gleichzeitig zugreifen, selbst Verwaltet. Der ausgefeilte Festplattencashing Mechanismus wird so ausgehebelt.

Wenn ich etwas zu sagen hätte: Niemals wieder Clearcase. Es hat gute Ansätze in der Bedienung und den Möglichkeiten, am Anfang war ich echt nicht dagegen abgeneigt. Aber die zunehmenden Performanceprobleme änderten meine Meinung.

In einem anderen Projekt mit doppelt soviel Entwicklern, das etwas größer ist, wird seit 5 Jahren das kostenlose cvs ohne große Probleme benutzt. Und mit Web-Browser-frontend ist es sogar mittlerweile richtig nett zu bedienen. (nicht signierter Beitrag von WiWieWiki (Diskussion | Beiträge) 11:34, 12. Mai 2007)

Si tacuisses! Zunächst einmal ist das hier nicht der Platz um die Performance von ClearCase zu diskutieren. Zugleich zeigt Dein Beitrag, dass Ihr wohl gleich eine Reihe von Dingen falsch gemacht haben müsst. Wenn die Datensicherung der VOBs (von welcher Größe reden wir hier eigentlich?) wirklich so ewig dauern würde, wie Du das darstellst, dann wäre CC nicht zu verkaufen. Mit der richtigen Hardware können Gigabyte große VOBs innerhalb von Sekunden weggesichert werden, mit oder ohne locking. Auch Deine Bemerkung zur Verteilung von mehreren Projekten auf verschiedene "Regions" zeigt, dass hier grundlegendes Wissen fehlte. Es gibt kaum einen Grund, einzelne Projekte auf unterschiedliche Regions/Registries zu verteilen, solange sie nicht in separierten Netzwerken (WAN) liegen - und auch dann können sie synchronisiert werden. Offensichtlich habt Ihr es geschafft, den CC cleartext cache so winzig zu konfigurieren, dass ihr keine Hits mehr hattet und so die Performance in den Keller gezwungen wurde. Und BTW: Ein Projekt mit 8 Entwicklern ist wohl eher als mittelklein einzustufen, es gibt Projekte mit vielen hundert Mitarbeitern, die CC erfolgreich einsetzen.
Fazit: Es gibt durchaus berechtigte Kritikpunkte an CC, aber Deine Bewertung hat nichts mit den realen Möglichkeiten und Performance von ClearCase zu tun. --Burkhard 22:31, 6. Mär. 2009 (CET)



QS-Informatik
Beteilige dich an der Diskussion!
Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+)


Begründung: Quellen --Crazy1880 17:23, 24. Nov. 2009 (CET)

Rational ClearCase ist eine Produktfamilie der Firma IBM zur Versionsverwaltung von Quellcode und anderen Softwareentwicklungsdaten.

Die versionsgestützte Bearbeitung unterstützt paralleles Arbeiten und definierte Veröffentlichungen (siehe auch Releasemanagement).

Die Ursprünge dieses Systems gehen auf DSEE (sprich: dizzy) von der Firma Apollo Computers in den achtziger Jahren zurück und wurde von der Firma Rational Software bis ca. 2004 eigenständig am Markt angeboten, seitdem gehört die Produktfamilie zum Produktportfolio der Firma IBM.

Der ClearCase Client integriert sich transparent in die entsprechenden Dateimanager (Explorer, TotalCommander etc.), so dass der Zugriff auf die entsprechenden Dateien ganz normal über gewohnte Tools möglich ist.

Außerdem gibt es für die Arbeit von entfernten Standorten einen Webclient und seit der Version 6 einen darauf aufsetzenden Remoteclient.

Besonderheiten[Bearbeiten | Quelltext bearbeiten]

  • UCM: Unified Change Management ist ein von Rational vordefinierter Prozess, der die Softwareentwicklung allgemein unterstützt. Das UCM Project enthält in der Regel mehrere Komponenten, die wiederum mehrere Dateien umfassen können. Der Entwickler arbeitet unter UCM auf eigenen Streams. Die Arbeitsaufträge (Activities) können mehrere zu ändernde Dateien umfassen. Definierte Stände (z. B. Releasestand) werden durch Baselines markiert, ähnlich dem Label unter ClearCase.
  • Integriertes Softwarebuildmanagement: ClearCase erlaubt durch die integrierten Build-Tools omake und clearmake die Nutzung von „derived objects“. Die beim Kompilieren entstehenden Objekte können im View oder VOB (Versioned Object Base) zwischengespeichert und beim nächsten Build wiederverwendet werden, so dass die Performance eines Softwarebuilds deutlich zunehmen kann. Auch kann man beim Build einen Configuration Record erstellen lassen, wo z. B. sämtliche für den Build verwendete Dateien mit entsprechender Versionsangabe gespeichert werden.
  • Integration mit anderen Rational Tools: Die Integration der diversen Rational Tools ermöglicht letztendlich die Nachverfolgung eines Merkmales von der Anforderungsspezifikation bis hin zu den entsprechenden Testfällen.

Weblinks[Bearbeiten | Quelltext bearbeiten]