Übergang von einem Quellcode-Kontrollwerkzeug zu einem anderen. Ratschlag bitte?

Question

Kürzlich wurde mir gesagt, ich muss unser Perforce-Repository auf TrueChange (McCabe TrueChange) migrieren. Ich hatte bis zu diesem Zeitpunkt noch nichts von TrueChange gehört. Ich habe bisher cvs, subversion, vss und force benutzt. Ich versuche, irgendwelche Worte der Weisheit in diesem Übergang zu finden und was von TrueChange zu erwarten ist. Ich habe es geliebt, mit Perforce zu arbeiten, und ich fand den Übergang ziemlich einfach.

Können Sie mir helfen? Ich benutze VS2005, RAD und CruiseControl.

Answer 1

Ich benutze TRUEchange seit September 1999 und ich denke, Sie haben Glück, dass Ihnen mitgeteilt wurde, dass Sie von Perforce zu TRUEchange migrieren müssen.

Ich habe mit einer Reihe von Open-Source-, hausgemachten und kommerziellen CM-Softwaresystemen gearbeitet und TRUEchange ist mit Abstand das beste Produkt, das ich jemals benutzt habe.

Vier Dinge, die TRUEchange so gut (es gibt mehr als vier - das sind vier Schlüssel sind) machen:

1. ändern Satz basiert anstelle von Datei diff basiert. Wenn 50 Dateien als Gruppe ausgecheckt, modifiziert und dann wieder eingecheckt werden, sind Änderungen an diesen 50 Dateien eine einzige Einheit, die als Änderungssatz bezeichnet wird. TRUEchange behandelt parallele parallele Baselines besser als jede CM-Software, die ich je benutzt habe. Csets können auf eine niedriger nummerierte Baseline migriert oder auf eine höher nummerierte Baseline migriert werden. Migrations-/Zusammenführungskonflikte sind selten und es gibt ein integriertes 3-Wege-Merge-Tool in den Clients, das dem Benutzer erlaubt, mit Konflikten äußerst einfach umzugehen. Änderungssätze können aus einer bestimmten Version (in beliebiger Reihenfolge) entfernt und wieder hinzugefügt werden. Wenn 5 Änderungen an einer Datei in 5 verschiedenen Änderungssätzen vorgenommen wurden, kann die zweite Änderung entfernt werden, während die Änderungen 1, 3, 4 beibehalten werden und 5 intakt. Es enthält auch vollständige Metadaten, um das Verschieben von Dateien von einem Verzeichnis zu einem anderen, das Umbenennen von Dateien oder das Umbenennen von Verzeichnissen zu unterstützen. Dateien können entfernt werden und es gibt einen Änderungssatz, der die Datei entfernt. Da der Änderungssatz, der die Datei entfernt, die Datei-ID, den Dateinamen und das übergeordnete Verzeichnis der Datei beibehält, können Dateien jederzeit wiederhergestellt werden, ohne sie erneut in das System laden zu müssen. Der Änderungsverlauf wird wiederhergestellt, wenn die Datei wiederhergestellt wird.

2. Projektversion basierend auf Dateiversion basiert. Wenn eine Version überprüft wird (ähnlich wie beim Tagging), wird der Inhalt aller Dateien im gesamten Projekt als eine Einheit aufgezeichnet. Anstatt die einzelnen Versionsnummern für 5000 Dateien zu verfolgen, müssen Sie nur die Prüfpunkte für die Projekte verfolgen, die diese Dateien enthalten. Die Verwaltung des Verlaufs der für die Qualitätssicherung oder Bereitstellung erstellten Informationen ist "todschick", da Dateiversionen nicht nachverfolgt werden müssen. TRUEchange verwendet Build-Konfigurationen, um verwandte Projekte zu gruppieren und die Dateipfade, in die die Dateien extrahiert wurden, für den Build-Prozess - auf Unix/Linux-, Windows- oder VMS-Dateisystemen. Wir verwenden eine Versionsnummer mit drei Segmenten wie 2.1.0. Der erste Build (oder die Iteration) für eine Version wäre 2.1.0.1. Die zweite wäre 2.1.0.2 und so weiter. Wenn wir einen Build ausführen und dieser abgeschlossen ist, nehmen wir die Details der Build-Konfiguration und fügen die Daten in zwei Datenbanktabellen ein. Eine Tabelle enthält die Build-Konfigurationsebene Informationen wie Build-Konfigurationsname, Hauptversionsnummer, Nebenversionsnummer, Unterversionsnummer, Iteration, beschreibenden Titel, Build-Typ (entweder QA oder Produktion) und Datum und Uhrzeit abgeschlossen. Die andere Tabelle enthält einen Fremdschlüssel, der auf die Zeile der Buildkonfigurationsebene in der ersten Tabelle verweist und den Projektnamen, die Hauptversionsnummer, die Nebenversionsnummer, die Unterversionsnummer und die Iteration von dem zum Ausführen des Builds verwendeten Prüfpunkt enthält. Mit den Informationen zur Buildkonfigurationsebene und den Informationen auf Projektebene können wir die Datenbank abfragen und sofort den genauen Inhalt jedes Buildlaufs kennen. Gegenwärtig haben wir seit September 2001 eine Geschichte für Builds - fast 33.500 Builds und über 228.000 Kinderaufzeichnungen.Innerhalb von ein oder zwei Minuten konnte ich die Quellverzeichnisstruktur für jeden Build-Lauf in den letzten 8 Jahren neu erstellen und weiß, dass es absolut genau und identisch mit dem Build-Lauf ist, der ursprünglich ausgeführt wurde. Wenn ich dies mit einem auf einer Dateiversion basierenden CM-System tun müsste, würde es ziemlich lange dauern, einen gegebenen Build neu zu erstellen.

3. Befehlszeilenbefehle, Windows GUI, Java GUI-Client (StreamCM), Anpassbarkeit und Zuverlässigkeit. TRUEchange verfügt über eine Vielzahl von Befehlszeilenbefehlen, die einen hohen Grad an Automatisierung ermöglichen. Mithilfe von Shell-Skripten und PHP konnten wir vollautomatische Build-Zyklen und angepasste Web-Interfaces entwickeln, mit denen Entwickler mit dem CM-System interagieren können. Entwicklungs-Builds werden ausgeführt, wenn der Konfigurationsverwaltungsbenutzer mit dem Abruf von Dateien aus TRUEchange von einer Webseite ausgeführt wird. Dies garantiert, dass von den Ingenieuren eingecheckter Code erstellt wird, wenn er von CM ausgeführt wird. StreamCM läuft auf einer Vielzahl von Plattformen - Unix (Solaris, AIX, HP-UX, Irix usw.), Linux (Red Hat, Fedora, Gentoo usw.), Windows (XP, Vista) und auf MacOS (PPC und Intel)). Diese einheitliche Schnittstelle ermöglicht es Entwicklern, mehrere Plattformen zu verwenden und den Client unabhängig vom Betriebssystem gleich zu verhalten. TRUEchange kann mit ihrer Skriptsprache stark angepasst werden. Wir haben TRUEchange angepasst, um mit unserer CM-Datenbank unter PostgreSQL zu interagieren, so dass webbasierte Anwendungen Metadaten aus einer Datenbank lesen können, anstatt das CM-System abzufragen. Wir haben auch TRUEchange angepasst, um über eine Verbindung zur Oracle-Datenbank mit unserem Problem-Tracking-System in Mercury Interactive Test Director zu interagieren. Es ist sehr zuverlässig. In fast 10 Jahren hatten wir einen Fehler in einem Repository, der aufgrund eines Festplattenfehlers zu einer Sicherung zurückkehren musste. Und da TRUEchange die Transaktionen verwaltet, die für jedes Repository gepostet werden, konnten wir die Transaktionen, die das Repository modifiziert haben, in der Reihenfolge wiedergeben, in der sie ursprünglich angewendet wurden. Es war ein wenig genutztes Repository, aber es dauerte nur 10 Minuten, um alle Transaktionen ab einem Zeitraum von drei Tagen wiederzugeben. Wir haben über 200 Benutzerlizenzen und wir hatten nie mehr als zwei CM-Ingenieure, um die Benutzerbasis zu unterstützen. Im Jahr 2008 haben der andere CM-Techniker und ich über 6300 QA-Builds durchgeführt und über 1800 Deployment-Images für die Produktionsbereitstellung erstellt. Verglichen mit jedem anderen CM-System, das ich jemals benutzt habe, erfordert TRUEchange viel weniger Administration - mit einem großen Vorsprung. Das andere Plus ist McCabes Bereitschaft, das Produkt basierend auf den Bedürfnissen seiner Kunden zu verbessern. Wir haben im Laufe der Jahre nach zahlreichen Verbesserungen gefragt und sie haben fast jede Anfrage erfüllt und unsere Erwartungen übertroffen. Das andere großartige an TRUEchange ist, dass es in einer verteilten Umgebung ausgeführt wird. Ein Lizenzmanager steuert den Zugriff auf das System und verfolgt, auf welchen Servern die Repositorys tatsächlich ausgeführt werden. Wir haben einen Lizenzserver und vier Linux-Server, auf denen 97 Repositories laufen. Wenn wir Server hinzufügen müssten, um zusätzliche Repositories unterzubringen, wäre es nur eine Frage der Server zu bringen, die Repositories zu erstellen (oder bestehende auf den neuen Server zu verschieben), die Start- und Stopp-Skripte neu zu erstellen (durch einen automatisierten Prozess) und Starten der Repositorys auf dem neuen Server. Es ist kein Client-Eingriff erforderlich. Und wir verwalten fast 52 Millionen Zeilen Quellcode plus Binärdateien (wie gif-Dateien, JPEG-Dateien usw.).

4. CruiseControl Plugin. Mit der neuesten Version der Software hat McCabe ein CruiseControl-Plugin entwickelt, das die TRUEchange-Integration ermöglicht. Wir haben CruiseControl zu diesem Zeitpunkt noch nicht verwendet, da unsere Software extrem komplex ist und viele Abhängigkeiten aufweist. Dies ist kein Mangel von TRUEchange, sondern ein Manko von CruiseControl. Es scheint am besten für Standalone-Systeme geeignet zu sein, die nicht stark von anderen Systemen abhängen.

Um von einem anderen CM Produkt zu TRUEchange itt zu leicht wandern lediglich ergreift das Konzept des Projektes im Vergleich zu Datei orientiert orientiert und dann die Repositories einrichten, um die Sicherheitsanforderungen zu erfüllen (wer, was und auf welcher Ebene zugreifen kann) und logische Projekte Organisation der Softwaresysteme. Wenn die Repositorys und Projekte korrekt eingerichtet sind, müssen nur die Dateien aus dem alten CM-System abgerufen und in die TRUEchange-Projekte geladen werden.