Methode zur Integration verschiedener Versionskontrollsysteme oder zur Auswahl eines Systems aufgrund von Fusionen und Übernahmen?

11

Unternehmen erwerben andere Unternehmen, die andere Versionskontrollsysteme verwenden.

Gibt es eine allgemeine Weisheit darüber, wie solche Systeme zusammen integriert werden können, beispielsweise mithilfe einer Subverson-GIT-Brücke, oder sogar, ob nur ein Tool über einem anderen verwendet werden soll - und wie zwischen Systemen migriert werden soll?

Verwenden die Leute eine Reihe von Kriterien für eine solche Entscheidungsfindung, zum Beispiel ein Äquivalent zum "Joel" -Test zur Softwareentwicklung?

version-control migration

— Therobyouknow
quelle

11

So beantworten Sie die Migrationsfrage aus persönlicher Erfahrung mehrerer Migrationen:

Haben Sie keine Angst davor, die aktuelle Version der Software als Basis in das neue Versionsverwaltungssystem zu integrieren und von dort aus zu arbeiten.

Die überwiegende Mehrheit der Zeit werden Sie die Geschichte nicht brauchen. Dies bedeutet, dass während der Integration eine Aufgabe weniger ausgeführt werden muss und weniger Fehler auftreten müssen.

Dateien / Projekte, die aktiv entwickelt werden, werden bald eine neue Geschichte generieren. Wenn Sie also herausfinden müssen, warum eine Änderung vorgenommen wurde, besteht die Möglichkeit, dass sich der Verlauf im aktuellen Repository befindet, da es sich um eine kürzlich vorgenommene Änderung handelt.

Dateien / Projekte, die vor der Migration stabil waren, sollten nach der Migration stabil bleiben (alle Dinge sind gleich), damit Sie nicht auf den Verlauf verweisen müssen. Wir haben festgestellt, dass es keinen wirklichen Vorteil hat, wenn wir einen Fehler in einer so alten Datei / einem so alten Projekt untersuchen müssen, dass der Verlauf vorliegt. Solange Sie das alte Repository 6 Monate / Jahr lang verfügbar halten, haben Sie in solchen Fällen die Referenz.

— ChrisF
quelle

+1 fairer Punkt, migrieren Sie nur das, was Sie benötigen, lassen Sie die alten Versionen im alten vorherigen Repository. Migrieren Sie nicht um ihrer selbst willen. Dieser Ansatz ist eine Variation des Ansatzes zur Wahl zwischen Organisieren und Suchen. Wenn Sie durch die Suche schnell das bekommen, was Sie wollen, müssen Sie nicht immer organisieren, was Sie suchen.

— Therobyouknow

1

+1 IMO die beste Strategie. Verwenden Sie weiterhin nur einen, die anderen für alle Fälle im schreibgeschützten Modus.

— user281377

1

+1: genauere Antwort auf den Migrationsteil.

— VonC

1

+1 - schwer genug, um den vorhandenen Code zu verstehen, geschweige denn die letzten drei Versionen.

— JeffO

1

Wir haben viele CVS-Repositorys mit dem coolen Skript cvs2svn in SVN konvertiert, was sehr gut funktioniert hat. Ich kann mich an niemanden erinnern, der die Geschichte über die "letzten Änderungen" hinaus nachgeschlagen hat, daher war dies den Speicherplatz nicht wirklich wert. Wenn ich es noch einmal tun würde, würde ich einfach das CVS-Repo markieren, bei SVN als neu einchecken und dann das CVS-Repo als schreibgeschützt markieren.

— JBRWilkinson

4

Auf der Managementseite geht es hauptsächlich um:

Support : Wird das Unternehmen, das das VCS veröffentlicht, im Falle von Problemen immer noch da sein?
Dies ist leider einer der Hauptgründe, warum solche veralteten Produkte wie ClearCase immer noch in Betracht gezogen werden (ClearCase ist seit 2003 ein ... IBM- Produkt).
Lizenzkosten : Selbst wenn es Freeware-Alternativen gibt, können manchmal "Gruppenlizenzen" für ein VCS ausgehandelt oder tatsächlich in einen viel größeren Vertrag aufgenommen werden, einschließlich Server, Netzwerke, Support usw. Eine globale Lizenz für diese Art von Produkt kann enden kostet viel weniger als der öffentliche Preis.

Auf der Projektseite geht es auch um:

Administration : Auf welchem Server installieren Sie ein VCS (oder viele VCS, wenn es sich um Git, SVN und andere handelt)? Mit welcher Sicherungsrichtlinie? Welcher DRP (Disastry Recovery Plan)?
lokaler Support : Wer wird den Level 1-Support in Anspruch nehmen? Level 2?
Marktkenntnisse : Sind Sie sicher, genügend Entwickler und / oder Administratoren mit den richtigen Kenntnissen zu finden, um dieses VCS und alle seine Funktionen zu nutzen?

Freeware oder nicht, denken Sie daran, dass eine "freie" Software kostenlos ist, wie in "Redefreiheit" (Sie können die gewünschte auswählen und bereitstellen), nicht wie in "Freibier" (es kostet immer noch viel Geld im Server , Backup, Administration, Support, ...)

Die oben genannten Kriterien sind ein Anfang, um zu bestimmen, welches VCS beibehalten und was aufgegeben werden soll.
Im letzteren Fall müssen Sie jedoch Folgendes berücksichtigen:

Migrationsstrategie : Können Sie einen Projektverlauf von einem VCS in ein anderes exportieren / importieren?
Brückenstrategie : Ist es sinnvoll, eine Historie in zwei verschiedenen VCS zu haben?
Projektveralterung : Wenn sich ein Projekt im Wartungs- / End-of-Life-Status befindet, ist es möglicherweise besser, ein altes VCS für kurze Zeit zu unterstützen.

— VonC
quelle

+1 gute Antwort, Aufzählungszeichen umreißen die Kriterien, nach denen ich suche, und Ihre Erklärungen mit ihnen helfen auch. Ich werde anderen eine Chance geben, bevor ich eine Antwort akzeptiere. Vielen Dank.

— Therobyouknow

1

Müssen Sie wirklich verschiedene Systeme integrieren? In unserem Team lebt jedes Projekt in einem eigenen Repository, und ihre Historien sind daher unabhängig. Wir haben hier kein Problem damit, mit einigen Projekten unter Subversion und anderen unter Quecksilber zu arbeiten, selbst wenn es Abhängigkeiten zwischen ihnen gibt.

Wenn Sie von einem VCS zu einem anderen migrieren möchten, sehen Sie sich die verfügbaren Konvertierungstools an. Meiner Erfahrung nach gibt es keinen technischen Grund, die Projekthistorie zu streichen.

Bearbeiten

Ich glaube, ich habe etwas verstanden, was in der Frage und in anderen Antworten enthalten war. Es ist die Tatsache, dass VCS auch zum Verwalten von Abhängigkeiten verwendet wird. Ich weiß, dass es durchaus üblich ist, VCS-Funktionen svn:externalszu verwenden, um ein Repo (die Abhängigkeit) in ein anderes zu integrieren.

Ich denke, der (technische) Grund, warum unser Team nicht das Bedürfnis hat, unsere zwei verschiedenen Systeme zu überbrücken (oder zu integrieren), ist, dass wir ein separates Tool zum Verwalten von Abhängigkeiten haben. Unser Repo kennt sich nicht.

— Barjak
quelle

Notwendigkeit der Integration verschiedener Systeme? Ja, wenn die Arbeit eines Teams von einem anderen Team verwendet wird. Die Integration kann je nach Bedarf und verfügbaren Personalressourcen eng sein oder verloren gehen. Nein, wenn die Projekte völlig unabhängig sind. Die einzige verbleibende Sorge ist die Unterstützung von mehr als einem System und ob dies als eine gute oder eine schlechte Sache empfunden wird. Gut, wenn wir akzeptieren, dass wir in einer abwechslungsreichen Computerwelt leben, oder schlecht, wenn wir der Meinung sind, dass wir uns konzentrieren und um ihrer selbst willen Entschlossenheit zeigen sollten, indem wir ein Tool selbst auswählen, das möglicherweise zu solipstistisch ist!

— Therobyouknow

PS. +1 Glück gehabt, Barjak, dass Sie in einer Organisation sind, die eine abwechslungsreiche Computerumgebung toleriert.

— Therobyouknow

0

Viele gute Antworten. Eine andere Sache, über die man nachdenken sollte, ist, die Teammitglieder nicht davonkommen zu lassen, zu denken, dass das Wechseln des VC eine so große Sache ist. Es wird einen Rückschlag bei der Migration, einer Lernkurve usw. geben, aber wenn sie zu viele Probleme haben, müssen sie ihre Fähigkeiten und / oder ihre Zusammenarbeit in Frage stellen.

— JeffO
quelle

+1 Ein Realismus hier. Die Menschen müssen die Nerven behalten, mutig sein und weitermachen. Risiken müssen genau definiert sein. Eine Erkenntnis, die ich an meinem Arbeitsplatz sehe und höre, ist, dass wir manchmal nicht hart genug arbeiten, um die Unsicherheit zu verringern / die Risiken / Eventualitäten klar zu definieren, bevor wir uns engagieren. Es scheint, dass es genügend Zeit für die Iteration gibt, aber nicht genug Zeit, um es beim ersten Mal richtig zu machen. Das Beheben von Problemen wird belohnt und als laufende Aktivität angesehen, auch wenn sie manchmal unnötig waren.

— Therobyouknow

1

Dies hängt von den betreffenden VCS ab und davon, wie gut die Migration durchgeführt wird. Der Wechsel von Git oder sogar CVS zu einem sperrenden VCS wird extrem erschütternd sein.

— David Thornley