![[HaBo]](/styles/default/logoklein.png){kind=small}
Hackse
0
Hallo Hackerfreunde,
vor 3 Jahren stellte ich eine Frage bez. SVN vs. GIT und nun steht der Umstieg vor der Tür. Wird ja auch Zeit.
Hauptproblem ist nicht der Einsatz von GIT, sondern das adäquate Umwandeln meines aktuellen SVN Repositories mit mehreren hundert Projekten nach GIT.
Mein SVN Repository ist wie folgt strukturiert:
Diese Strukturierung hat sich für mich als sehr praktisch und flexibel herausgestellt, da ich hiermit via SVN sowohl das komplette Repository, als auch alle Projekte einer Programmiersprache, als auch ein einzelnes Projekt, als auch eine einzelne Version eines bestimmten Projektes auschecken kann (aus dem trunk- oder tags-Zweig). Diese Flexibilität ist für mich unerlässlich und muss nach der Überführung des SVN-Repositories nach GIT wieder hergestellt werden.
Aktuell habe ich das komplette SVN-Repository mal in ein einziges GIT Bare-Repository umgewandelt (via git-svn). Da GIT meines bisherigen Wissens nur komplette Repositories klonen kann und im Gegensatz zu SVN keine einzelnen Ordner oder Dateien auschecken kann, ist es mir aktuell nur möglich das GIT Bare-Repository komplett als Workingcopy zu klonen, was sehr unschön ist, da es mehrere GB groß ist.
Es muss nun dieses GIT-Repository in Programmiersprachen und dann innerhalb der Programmiersprachen in Projekte unterteilt werden wie oben dargestellt, so dass ich weiterhin sowohl eine Gesamtheit von Projekten innerhalb einer Sprache als auch jedes Projekt spezifisch klonen und bearbeiten kann.
Ich habe über GIT-Konzepte wie Submodules als auch Subtrees gelesen, rede mir ein verstanden zu haben was diese sind und wie diese funktionieren. Da ich jedoch hunderte von Projekten in SVN habe, suche ich nach einem Weg der Strukturierung, die nur endlich viel Aufwand darstellt.
Ein Aufteilen aller Projekte in Submodules wäre sehr viel Aufwand.
Was ist denn ein in endlicher Zeit durchführbarer und typischer Weg des Umwandelns komplexer SVN-Repositories nach GIT und anschließender Strukturierung?
Greetz
Hackse
vor 3 Jahren stellte ich eine Frage bez. SVN vs. GIT und nun steht der Umstieg vor der Tür. Wird ja auch Zeit.
Hauptproblem ist nicht der Einsatz von GIT, sondern das adäquate Umwandeln meines aktuellen SVN Repositories mit mehreren hundert Projekten nach GIT.
Mein SVN Repository ist wie folgt strukturiert:
Code:
C/prj_1 (trunk, branches, tags)
C/prj_2 (trunk, branches, tags)
C/prj_n (trunk, branches, tags)
Java/prj_1 (trunk, branches, tags)
Java/prj_2 (trunk, branches, tags)
Java/prj_n (trunk, branches, tags)
Python/prj_1 (trunk, branches, tags)
Python/prj_2 (trunk, branches, tags)
Python/prj_n (trunk, branches, tags)
Perl/prj_1 (trunk, branches, tags)
Perl/prj_2 (trunk, branches, tags)
Perl/prj_n (trunk, branches, tags)
...Aktuell habe ich das komplette SVN-Repository mal in ein einziges GIT Bare-Repository umgewandelt (via git-svn). Da GIT meines bisherigen Wissens nur komplette Repositories klonen kann und im Gegensatz zu SVN keine einzelnen Ordner oder Dateien auschecken kann, ist es mir aktuell nur möglich das GIT Bare-Repository komplett als Workingcopy zu klonen, was sehr unschön ist, da es mehrere GB groß ist.
Es muss nun dieses GIT-Repository in Programmiersprachen und dann innerhalb der Programmiersprachen in Projekte unterteilt werden wie oben dargestellt, so dass ich weiterhin sowohl eine Gesamtheit von Projekten innerhalb einer Sprache als auch jedes Projekt spezifisch klonen und bearbeiten kann.
Ich habe über GIT-Konzepte wie Submodules als auch Subtrees gelesen, rede mir ein verstanden zu haben was diese sind und wie diese funktionieren. Da ich jedoch hunderte von Projekten in SVN habe, suche ich nach einem Weg der Strukturierung, die nur endlich viel Aufwand darstellt.
Ein Aufteilen aller Projekte in Submodules wäre sehr viel Aufwand.
Was ist denn ein in endlicher Zeit durchführbarer und typischer Weg des Umwandelns komplexer SVN-Repositories nach GIT und anschließender Strukturierung?
Greetz
Hackse
