Versionskontrolltool, das mit anderen Versionskontrolltools interoperabel ist

Wir beginnen mit der Neubewertung von Versionskontrollsoftware, die in unserem Unternehmen verwendet werden soll. Wir haben uns vor etwa 15 Jahren für ClearCase und vor sechs Jahren für Subversion entschieden, daher haben wir noch einige Umgebungen mit ClearCase-VOBs, die die ClearCase-GUIs verwenden, und neuere Umgebungen, die Subversion-Repositories und einige GUIs wie TortoiseSVN verwenden.

Im Laufe der Zeit haben sich einige Projekte die Mühe gemacht, von ClearCase zu Subversion zu migrieren, aber wir haben immer noch einige, die weiterhin an ClearCase festhalten, weil es funktioniert hat.

Git scheint heutzutage bei vielen Leuten die beliebteste Wahl zu sein, aber ich frage mich, ob wir das Problem in zwei oder drei Unterprobleme aufteilen können:

  • Wählen Sie ein einziges Back-End-Versionskontrolltool (z. B. Git), um nur die Repositories zu hosten.
  • Wählen Sie bei Bedarf ein oder mehrere Versionskontrolltools (z. B. Git, git-svn, git-hg, git-cc, GitSwarm) aus, die die Teams verwenden, um mit den Back-End-Repositories zu interagieren, oder lassen Sie die Teams ihre eigenen Tools auswählen.
  • Wählen Sie grafische oder webbasierte Frontends (z. B. TortoiseGit, Stash, SourceTree) aus, um mit den ausgewählten Versionskontrolltools zu interagieren, oder lassen Sie die Teams ihre eigenen Tools auswählen.

Dies kam heraus, nachdem wir das Folgende über duale Repositories gelesen hatten, damit die verschiedenen Teams ihren aktuellen Workflow weiterverfolgen können, bis sie bereit sind, mit Git oder was auch immer wir uns letztendlich für eine Migration entscheiden, an Bord zu gehen:

Das Back-End-Versionskontrolltool sollte:

  • Geringe oder keine Lizenzkosten.
  • Unterstützt Windows- und Linux/UNIX-Repositories sowie Clients.
  • Idealerweise interoperabel mit den Legacy-Produkten ClearCase und Subversion, damit Teams diese Produkte weiterhin verwenden können, bis sie sich für eine Migration entscheiden.
  • Bietet eine hervorragende Leistung, sodass der Betrieb nicht mehr verlangsamt wird, als dies derzeit mit den ClearCase-VOBs und Subversion-Repositories der Fall ist.
  • Halten Sie die Repository-Daten in einem offenen Format und nicht in einem proprietären Container, damit wir die Repositorys bei Bedarf in weiteren 5-15 Jahren problemlos auf ein anderes Tool migrieren können.

Wenn dies möglich ist und empfohlen wird, gibt es dann geeignete Versionskontroll-Repositories, die wir untersuchen und vergleichen können?

Ich bezweifle, dass irgendein Versionskontrollsystem ein Standardformat verwendet. Bisher habe ich gesehen, dass Subversion, Git und Mercurial jeweils ein proprietäres Format verwenden. Auf jeden Fall können Sie die Interoperabilität nutzen, um später die gesamte Projekthistorie in ein anderes System zu kopieren.
Git und Bazaar verfügen über eine hervorragende bidirektionale Kommunikation mit SVN und praktisch allen anderen VCS-Systemen.
@Alejandro du meinst wahrscheinlich ein benutzerdefiniertes Format. Keines dieser Formate ist proprietär. Außerdem haben Tools wie Reposurgeon und andere das Format git-fast-import als Quasi-Standard etabliert. Aber es ist normalerweise viel Aufwand erforderlich, um es bidirektional zu machen (außer mit Git und seiner Subversion-Bridge).

Antworten (1)

Git bietet eine solche Funktionalität mit SVN. Es bietet im Grunde einen bidirektionalen Fluss zwischen einem Git-Repository und einem SVN-Repository und verschiedene Befehle zum Verwalten dieser Verbindung.

Versionskontrolltool, das mit anderen Versionskontrolltools interoperabel ist
AntwortenHierDatenschutz-Bestimmungen1y, 0v