Migration von svn zu git (subtree, submodule oder Ordner)

[Alex2005]

Bei uns in der Arbit wollen wir von SVN zu GIT umziehen, da die Infrastruktur ebenfalls von svn zu GIT (Bitbucket) migriert wurde.

SVN wurde nur zum Erstellen einer Änderungshistorie verwendet. Keine Branches, Merges, Tags, nur einfach Commits. (alles ein oder zwei Mann Projekte)

Wie man von svn zu git kommt ist nicht das Problem, das läuft.
Die Frage ist, wie man die vorhanden Projekte/Order am Besten organisiert.

Bisher (Alles ein Team):
- Eine Person A arbeitet am Code commited Änderungungen im SVN
- Einzelne "Projekte"(20Stk) sind in Ordner mit je einem SVN Repo abglegt, die Ordner haben eine geringe Tiefe
- Änderungen am Code werden lokal?? gepflegt und anschließend per CopyPaste in das Server SVN gebracht (Fragt nicht, wie das genau gemacht wird)

- Weitere Person B arbeitet ohne Codeverwaltung in Ordnerstruktur, diese soll Initial ins GIT abgelegt werden

Zukünftig:
- Projekte von Person A sollen teilweise als Bibliothek verwendet werden, auch mit Zugriff von einer Person C(Andere Abteilung)

Bisher hab ich mir folgendes gedacht, die Repos sollen alle ins Team-Bitbucket kommen, weitere Team-Buckets soll es nicht geben
1. Ein einziges Repo in dem alle Projekte von Person A nur als Ordner abgelegt sind, weiteres Repo in dem alle Projekte von Person B ebenfalls als Ordner abgelegt werden
2. Jedes Projekt von Person A und B als eigenes Repo und dann ein Sammelrepo (submodule
3. Subtree, wobei ich da noch nicht verstanden was der Unterschied zu submodule ist


Wunsch ist das ganze so einfach wie möglich zu halten, da wir hier keine (Hardcore)-Programmierer sind. Soviele sinnvolle Funktionen von Git zu nutzen, ohne sich in Details zu verkünsteln.

 

[Bagbag]

Option 1 würde ich auf keinen Fall machen, da hast du dann alle Commits vermischt. Wenn du bei einem Projekt etwas Rückgängig machen willst oder auf einen anderen Stand möchtest, musst du immer auch aufpassen, an den anderen Projekten nix kaputt zu machen, etc., etc. ...

Subtrees sagten mir bisher auch noch nichts, ist jedenfalls kein natives Feature von git. Scheinbar nutzt man hier auch einfach nur Unterordner im Hauptrepo. Ich habe gerade nur ein klein wenig dazu gelesen, aber das würde ich submodules wohl nicht vorziehen. Da ich als Vorteil u.A. etwas wie "funktioniert auch in ganz alten Git-Versionen" gelesen habe, ist das wohl auch entstanden, bevor es submodules gab.

Also bliebe für mich hier nur noch submodules oder, je nachdem um was für Projekte es sich handelt, dafür gemachte Package-Manager wie npm, pip, nuget etc..
Und hier dann eindeutig die Package-Manager vor submodules.

 

[benneq]

Warum nicht einfach so weitermachen wie bisher - also ein Repo für alle(s)? Ist einfach und macht am wenigsten Ärger. Und ihr habt schon Erfahrung mit dieser Struktur.

Submodule sind auch relativ einfach, allerdings funktioniert da nichts automatisch. D.h. sobald sich an einem Submodul etwas ändert, musst du dem Hauptmodul sagen, dass es sich doch bitte die Änderungen vom Submodul ziehen soll und dann musst du einen neuen Commit im Hauptmodul erstellen. (Subtrees sind "ähnlich", allerdings bin ich damit nie warm geworden und habe mir mehrmals mein Repo zerschossen und irgendwann aufgegeben )

Die Submodule bringen eigentlich nur Vorteile, wenn man so ein Submodul gleichzeitig in mehreren anderen Modulen eingebunden ist und dabei auch auf unterschiedliche (nicht-master) Versionen des Submoduls verwiesen wird.

In meinen Projekten habe ich festgestellt, dass das (fast) nie der Fall ist. Also haben wir die Submodule wieder abgeschafft.

Da ist es einfacher, wenn sich jedes Team einen eigenen Branch aufmacht und dieser dann bei Bedarf gemerged wird.

 

[Sgt_H4rtman]

Hallo Alex,

ich kann jetzt nicht behaupten, dass ich deine Ausführungen ganz verstanden habe, aber die Aussage von wegen keine großartigen Git Features nutzen zu wollen und dann nach Subtrees und Submodules zu fragen passt nicht so recht zusammen. Diese beiden Features wurden für gigantische Repositories entwickelt, wo mehrere Teams an (un)abhängigen Komponenten arbeiten, die gemeinsam in einem Binary released werden sollen. Populärstes Beispiel hierfür ist der Linux Kernel.

Daher erstmal ein paar grundsätzliche Fragen.
1. Haben die Projekte miteinander etwas zu tun oder sind sie komplett unabhängig?
2. Was bedeutet der zweite Entwickler hat ohne SVN gearbeitet? Habt ihr zwei oder gar mehr unterschiedliche Stände ein und des selben Projektes?

Grundsätzlich sollte (Streich den Konjunktiv).... muss sich jeder Entwickler mit einem VCS auseinander setzen. Und gerade Git hat das so einfach gemacht, dass es da keine Entschuldigung für gibt.

Ein wenig klingt das wie Framework/Library und eine/mehrere Anwendung(en) welche erstere verwenden. Wenn dem so ist, dann sollen sich die Kollegen mit Package Managern (Composer für PHP, NPM für Javascript, PIP für Python, etc.) auseinander setzen. Sowas löst man nicht mit dem VCS. Du schlägst ja auch keinen Nagel mit der Rohrzange in die Wand.

Wenn es jetzt schon einzelne SVN Repositories sind, dann einfach mehrere Git Repositories draus machen. Und wie gesagt Subtrees / Submodules (SVN Externals) sind keine sinnvolle Alternative für Package/Dependency Manager.

 

[Ruheliebhaber]

Wenn ich lese, wie Ihr SVN bisher genutzt habt, dann würde ich sagen, Ihr tut Euch keinen Gefallen, wenn Ihr auf GIT umstellt.

Es sei denn, Ihr habt viel Zeit zu üben und viele Backups zu machen.

Mein Vorschlag wäre, setzt Euch zusammen und diskutiert erst einmal, was Eure Anforderungen sind und wie die Prozesse aussehen sollen.
Wenn das klar ist, dann könnt Ihr Euch für eine Versionsverwaltung entscheiden.

GIT ist nicht per se besser oder schlechter.
Aber man muss gewaltig umlernen, wenn man bspw. von SVN kommt und kann viel falsch machen.

 

[benneq]

Naja, wenn man es ausschließlich mit push, pull und merge benutzt, dann ist Git schon extrem einfach.

Unter macOS kann ich "Tower" als GUI empfehlen. So schön (und einfach) habe ich noch nie mit Git gearbeitet. Es gibt aber auch für Windows und Linux einen Haufen Alternativen.

 

[Ruheliebhaber]

Da will ich nicht widersprechen.

Aber lies bitte noch einmal:

Person A: Änderungen am Code werden lokal?? gepflegt und anschließend per CopyPaste in das Server SVN gebracht (Fragt nicht, wie das genau gemacht wird)

Weitere Person B arbeitet ohne Codeverwaltung in Ordnerstruktur,

Da gibt es ein paar konzeptionelle Probleme.
Die Leute müssen abgeholt und begleitet werden.
Ob GIT, SVN oder irgendetwas anderes ist bei dem Zustand eher Nebensache bzw. eine Gefahr, wenn das Werkzeug zu kompliziert ist.

Ansonsten zur Frage:

Klar kann man für jedes Projekt ein eigenes Repository machen.
Oder man tut alles in ein Repository.
Hat alles Vor- und Nachteile.

Die Frage ist, wie geht es danach weiter?
Das sind die Fragen, die ich andeuten wollte.
Softwareentwicklung besteht aus einer ganzen Reihe von Aufgaben.

Wie dokumentiert Ihr Anforderungen und Bugs?
Wie trackt Ihr Aufgaben und verknüpft das mit dem Code?
Wie verwaltet Ihr Code?
Wie versioniert Ihr Eure Software (in dem Sinne Version oder Release)?
Wie erstellt Ihr einen Build?
Wie deployed Ihr Eure Software?
Wie erstellt Ihr Patches oder Hotfixes?

Bei all diesen Fragen ist die Versionskontrolle nur ein kleiner Baustein?

Der Trend geht zu Continous Delivery.
Da gibt es eine ganze Reihe an Werkzeugen.

Erzähl mal ein bisschen mehr.
Welche Betriebssystemumgebungen setzt Ihr ein?
Welche IDE?
Welche Sprache?
usw.

Es gibt so viele Möglichkeiten.
Ein Setup könnte z.B. aus folgenden Komponenten bestehen:

- Windows (OS)
- Visual Studio (IDE)
- GIT (VCS)
- Team City (Build)
- Octopus (Deployment)

Kann gut sein.
Muss aber nicht.
Wie gesagt, es gibt so viele Möglichkeiten.
Keine Ahnung, was für Euch am besten passt.
Das hängt sicher auch von der Zeit und dem Budget ab.

 

[Alex2005]

Erstmal vielen Dank für die vielen guten Antworten. Dies hilft mir ungemein bei uns die richtigen Fragen zu stellen. Falls mein erster Post etwas wirr und unwissend rüberkam, dann ist das einfach nur ein Spiegel der Realität/meines Wissens xD.
Vorweg zur Info: Es geht einmal und Excel-VBA und einmal um DXL-Skripte.
Programmieren ist nicht unser Kerngeschäft, es ist notwendig, um die Aufgaben im Kerngeschäft (aber auch hier nicht überall) zu vereinfachen bzw. zu unterstützen.
Für mich nehme ich Git zum dokumentieren meiner Änderungen (HTML Seite für Sharepoint und ein wenig SQL), um nachzuvollziehen, wann ich was geändert habe.
Zukünftig ist der Wunsch, dass es eine Bibliothek (VBA) gibt. Die Wiederverwendung von Code erfolgt Dateiebene. Es soll festgehalten werden, welche Version mit dem Kunden ausgetauscht wurde. Wie ich gelernt habe ist hier ein Deployment-Tool besser geeignet.

Daher erstmal ein paar grundsätzliche Fragen.
1. Haben die Projekte miteinander etwas zu tun oder sind sie komplett unabhängig?
2. Was bedeutet der zweite Entwickler hat ohne SVN gearbeitet? Habt ihr zwei oder gar mehr unterschiedliche Stände ein und des selben Projektes?

1. Die beiden Projekte (vba und dxl) der beiden Personen sind komplett unabhängig. Ob alle Projekte/Ordner von Person A unabhängig sind, kann ich nicht sagen.
2. D.h., das meines Wissens die Skripte unter keiner Versionskontrolle stehen, wenn doch dann auch nur einfache lineare commits um Änderungen festzuhalten

Du schlägst ja auch keinen Nagel mit der Rohrzange in die Wand.

Hab ich auch schon gemacht^^

Wenn ich lese, wie Ihr SVN bisher genutzt habt, dann würde ich sagen, Ihr tut Euch keinen Gefallen, wenn Ihr auf GIT umstellt.

Das ist leider keine Option. Der SVN Server wurde abgeschalten. man könnte sich einen SVN hinstellen, ist dann aber für Backups und Wartung selbst verantwortlich. Bei GIT wird das von der IT übernommen.

Es sei denn, Ihr habt viel Zeit zu üben und viele Backups zu machen.

Jetzt in der Weihnachtszeit schon.

Unter macOS kann ich "Tower" als GUI empfehlen

Bei uns wird Sourcetree verwendet, alle anderen Tools müssten händisch durch die IT installiert werden. Aus dem persönlichen Gebrauch kenne ich noch ein wenig in Fork und Gitkraken.

Wie dokumentiert Ihr Anforderungen und Bugs?

Werde ich mal fragen.

Wie verwaltet Ihr Code?
Wie versioniert Ihr Eure Software (in dem Sinne Version oder Release)?
Wie erstellt Ihr einen Build?
Wie deployed Ihr Eure Software?
Wie erstellt Ihr Patches oder Hotfixes?

Diesen Block an Fragen, werde ich ebenfalls mitnehmen, bevor ich hier Vermutungen anstelle
Ein Deployment wird nicht systematisch gemacht, wenn dann nur in Excellisten. Ob es da bereits ein Tool im Unternehmen gibt, werde ich herausfinden.
Fehler können aber mit Jira getrackt werden. Jira ist bei uns auch mit dem Bitbucket "verbunden". Umgesetzt wird das aber bei uns im Team definitiv nicht.

Welche Betriebssystemumgebungen setzt Ihr ein?
Welche IDE?
Welche Sprache?

1. Win7 und Win10
2. Keine IDE, vba und dxl werden in den internen Editoren der Programme geschrieben. Ich persönlich verwende vscode und dbeaver für sql. Allerdings nicht um zu debuggen, sondern mehr wie einen simplen Editor.
3. vba dxl sql ein wenig html

Bzgl. dem Zeit und Kostenproblem, wenn man es richtig machen will (in unserem übersichtlichen einfachen Rahmen), dann muss man sich die Zeit eben nehmen. Dann muss man das ganze natürlich auch die Umsetzung sauber dokumentieren, damit das Wissen nicht mehr verloren geht.
Das Zeitproblem ist vorrangig eines der Kosten und da muss man den Chef einfach überzeugen, dass es notwendig ist.
Gibt es den Literatur zu dem Thema, welche ihr empfehlen könnt? Hiermit meine ich Literatur, die einen bei der Einführung an die Hand nimmt, um die richtigen Fragen zu stellen, ähnlich wie ihr es schon gemacht habt.

 

[Sgt_H4rtman]

Wow jetzt hast du mich echt kalt erwischt. Musste erstmal googeln, was DXL ist. Ok es geht hier also um (Semi)professionelle Office Suite Anpassungen. Da ergibt das mit dem manuellen übertragen ins SVN auch Sinn. Als ich das letzte mal mit VBA zu tun hatte waren die Makros noch fest in binäre Office Dokumente eingebettet. Keine Ahnung ob das mit dem XML Format geändert wurde, aber klingt ja eher nicht danach. Ich gehe jetzt mal davon aus, dass deine Kollegen ihre Änderungen mehr oder weniger manuell aus den Office Dokumenten in einzelne physische Dateien sichern und dann die Commits tätigen um die Historie zu speichern. Wenn ich mich recht entsinne konnte man den Code in einzelne logische Module gliedern. Dann ergibt das Vorgehen total Sinn und ich bleibe meiner Empfehlung, dass die jetzigen SVN Repositories einfach nach Git migriert werden können. Die Tools in den Office Suiten sind für einen solchen Grad an Softwareentwicklung natürlich nicht ausgelegt. Es bleibt also wahrscheinlich der manuelle Aufwand.

Ihr solltet euch aber mal das hier anschauen: https://github.com/rubberduck-vba/Rubberduck/blob/next/docs/About.md
Prinzipiell lässt sich der Editor also erweitern. Unter Umständen hat ja jemand auch einen GIT/SVN Connector als Add-In geschrieben.
In diesem Thread stehen einige interessante Projekte https://stackoverflow.com/questions/2996995/how-to-use-version-control-with-vba-code

 

[Ruheliebhaber]

Eine Erfahrung der letzten Jahre bei mir lautet "Tooling ersetzt keinen Konsens".
Setzt Euch zusammen und beratet, was Ihr braucht, um Eure Arbeit gut zu machen.
Der eine schraubt gerne per Hand, der andere schraubt gerne mit dem Akkuschrauber.
Am Ende ist jeder irgendwann fertig.
Der eine war etwas langsamer und hat Muskelkater im Unterarm.
Der andere war schneller, hat dafür aber jeden 5. Schraubenkopf rund gedreht.

Zum Einstieg in das Thema "Continuous Integration" und "Continuous Delivery" reichen auch die Wikipedia-Artikel.
Geeignete Tools finden sich dann meist, indem man sich anschaut, was es für die aktuell verwendete Technologie alles gibt.

Eine andere Weisheit ist "Keep it simple".
Klingt abgedroschen, ist aber unglaublich wahr.
Gerade in einer Branche, in der die Leute sich gerne in Technologie "verlieren".

Einfach ausgedrückt.

Wenn Ihr es schafft, ein "Ein-Klick-Deployment" hinzubekommen, vielleicht noch mit dem einen oder anderen automatischen Test, Versionierung, Paketierung und Backup, dann seit Ihr ganz weit vorne.

Ob Ihr das mit Batch-Dateien oder ein aktuell angesagtem Werkzeug macht, ist eigentlich egal.
Es geht um das Konzept.

Der Aufbau so einer Lösung kostet erst einmal.
Der Nutzen stellt sich aber relativ schnell ein.

Noch ein Tipp zu GIT.

Jede Änderung, jedes Feature wird in einem eigenen Branch entwickelt.
Anschließend wird der Branch in den Master gemerged.
Auf dem Master wird nie direkt entwickelt.
Releases werden in eigenen Release-Branches erstellt, die vom Master abzweigen.
Entwicklungsbranches können relativ zügig wieder gelöscht werden.
Release-Branches hebt man besser lange auf, um Hotfixes auf Releases entwickeln zu können.

Schau Dir einmal "Git Flow" an:

Hier der Blog vom "Erfinder": https://nvie.com/posts/a-successful-git-branching-model/

Vielleicht ein bisschen oversized für Euren Anwendungsfall, aber es erklärt noch einmal schön, was ich oben angerissen habe.

 

[Alex2005]

Vielen Dank für die Hilfestellung, ich hab hier wieder einige Anregungen gefunden, mit denn ich wieder Input bekommen habe, um das Bild zu kompletieren.
Für den Anfang werden wir erstmal mit einem Repo pro Projekt anfangen und die bisherigen SVN-Repos (20 Stk.) in Ordner umwandeln.
Wenn es in Zukunft "wilder" wird, kann man sich immer noch submodule oder subtrees anschauen, ggf. auch eine eigenes Bitbucketprojekt/Seite.
Nun steh ich noch vor dem Problem, die 20 SVN2Gits-Repos und deren Commits in ein einziges Git-Repo zu bekommen. Am liebsten würde ich ja einen harten Schnitt machen, die 20 konvertierten Gits in einen .old Ordner legen für die Historie und im Git komplett neu anfangen. Ob ich den Kollegen davon überzeugen kann wage ich aber zu bezweifeln.
Was meint ihr dazu?