Das ist vielleicht ungewöhnlich, also lassen Sie mich die Szene festlegen:Quelle gleichzeitig unter git und svn verwalten - macht es Sinn?
Wir haben ein SVN Repo mit unserer Projekthistorie - ein eingebettetes System auf Linux-Basis. Das SVN Repo enthält Linux Kernel, U-Boot, Busybox usw. Quellen und all unsere internen Apps, Dateisystem und so weiter.
Der Linux-Kernel, den wir haben, ist alt und krustig und ich arbeite an der Portierung auf die Mainline, die für unsere Plattform (n) aktiv entwickelt wird. Ich mache die kernseitige Arbeit unter git und tausche Patches mit "The Community".
Ich könnte Dinge arbeiten und einen Schnappschuss der Kernel-Quellen machen und es in SVN ablegen, aber ich würde gerne die Fähigkeit behalten, Updates zu erhalten, lokale Zweige zu haben und Patches mit git zu verwalten. Ich könnte zwei Kopien des Kernels behalten, einen, der von jedem SCM verwaltet wird, aber das wäre ein bisschen unordentlich. Es gibt auch Risiken der Entwicklung und des Testens unter Verwendung von Kernquellen, die unter git verwaltet werden, und vergessen, diese Änderungen in SVN zu bringen, was zu kaputten SVN-Versionen führt, in denen die Nichtkernquellen nicht synchron sind.
Die Migration des gesamten Projekts auf Git ist keine Option. Es ist möglich, nur die Kernel-Quelle mit git zu verwalten und eine Reihe von Leim-Skripten und gespeicherten Hashes in SVN zu haben, aber es ist schöner, eine einheitliche History/Diffing-Fähigkeit von SVN für das gesamte Projekt zu haben.
Was ich in Betracht ziehe, versucht, die Kernel-Quellen unter SVN und Git gleichzeitig im selben Verzeichnis zu verwalten.
Als Kernel-Entwickler würde ich meistens git verwenden und einen SVN-Commit für den internen Gebrauch machen, wenn die Dinge gut aussehen. Für andere interne Benutzer wären sie in der Lage, die gesamten konsistenten Quellen mit einem SVN-Checkout zu erhalten, eine einheitliche Historie zu sehen und sie könnten unter SVN Änderungen an den Kernelquellen vornehmen. Später kann ich oder eine andere git-benutzende Person SVN auf diese Änderungen aktualisieren und sie zu git wie erforderlich verpflichten.
Einige Dinge, die darauf warten, Git zu bekommen, um .svn-Dateien zu ignorieren und umgekehrt, müssen erledigt werden. Ich bin mir auch nicht ganz sicher, wie man einen einfachen SVN-Checkout machen und git anweisen würde, auch den Kernel-Teilbaum zu verwalten, aber ich bin mir sicher, dass git einige obskure swiss-army-messer-Optionen besitzt.
Also das ist meine Idee du jour. Es bedeutet, dass die meisten Mitarbeiter sich keine Sorgen um Git machen müssen, und wir können später ignorieren, wie es geht.
Die Frage hier ist wirklich, hat jemand so etwas getan, wie hat es geklappt, oder welche alternativen Lösungen haben Sie sich ausgedacht?
Im Anschluss habe ich das jetzt schon eine Weile gemacht und es funktioniert gut. – blueshift
Was ist, wenn Sie dieses Setup jemals auf ein anderes Gerät klonen müssen? Wenn ich zum Beispiel ein Verzeichnis unter git control habe, dann füge es svn mit den entsprechenden Ignores hinzu, möchte aber dasselbe Setup auf einem anderen Rechner haben. Müsste ich den Git Repo klonen und dann versuchen, den Svn Repo in dieses Verzeichnis zu überprüfen? Umgekehrt? –
Herausgefunden, dass Sie tun können, was ich gefragt habe, indem ich Git klonen dann 'svn checkout --force', um die beiden Repos zu kombinieren. –