Hallo,
Meine persönliche Empfehlung ist, ein git Repo auch mit Git zu holen und nicht auf ein
svn repo zu konvertieren.
Dann must du mir jetzt aber auch verraten, wie das mit
svn:externals funktionieren soll.
Ich habe mir git mal genauer angeschaut.
Erster Kritikpunkt: Die meisten Anleitungen zu git zeigen nur stumpfsinnige Kommandozeilenbefehle. Ist ja schön das man git auch im Script verwenden kann (native Powershell-Unterstützung scheint aber zu fehlen), aber die Welt ist bunt. Für die tägliche Arbeit muss der Standard klickibunti sein. Sinnvoll gestaltete Dialoge die einem bei der Arbeit unterstützen, anstatt stundenlang zu überlegen und zu testen was man wie in einen Texteditor schreiben muss, damit das richtige passiert.
Zweiter Kritikpunkt: Git unterstützt keine Dateisperren. Und wenn dann nur über irgendwelche komplizierten nichtvollfunktionsfähigen Hacks. In allen Projekten wo ich beteiligt bin gehören auch Binärdateien (Exe,
Dll, Bilder, Icons, Word, Excel usw.) dazu. Binärdateien kann man schlecht mergen. Deshalb dürfen diese nicht von mehreren gleichzeitig geändert werden. Dies muss man dem Versionsverwaltungssystem mitteilen können und es soll sich dann auch dem entsprechend verhalten.
Dritter Kritikpunkt: Die Terminologie und Funktionsweise von git weicht dermaßen stark von bisher bekanntem ab, dass man zu viel umdenken und neu lernen muss.
Summa summarum einen Wechsel von
SVN zu git bekomme ich beim Kunden nicht durch. Ich selbst würde ja nicht mal zu git wechseln. Es muss mit
SVN funktionieren und zwar einfach. Und laut
https://blog.subgit.com/line-endings...it-and-subgit/ soll es ja auch funktionieren.
Bei allen Projekten, wo ich beteilig bin, gibt es zwei Kommandos, die die Runde machen.
Erstes „Ich habe eingecheckt, Packages müssen NICHT kompiliert werden“ -> alle Kollegen wissen Entwicklungsumgebung schließen, Update auf einem Repository, Entwicklungsumgebung starten und alles ist schick, da weitermachen wo aufgehört.
Zweites „Ich habe eingecheckt, Packages müssen kompiliert werden“ -> alle Kollegen wissen Entwicklungsumgebung schließen, Update auf einem Repository, Entwicklungsumgebung über ein anderes Powershell-Skript starten, letzte Projekt der mit geöffneten Projektgruppe neu erzeugen und installieren, alles speichern, in der Liste der zuletzt geöffneten Projekte das oberstes Projekt öffnen und alles ist schick, da weitermachen wo aufgehört.
Diese Arbeitsabläufe müssen so funktionieren, sonst kann man keine Softwareentwicklung im Team betreiben. Ein Team fängt dabei schon bei einer Person an. Ich möchte nicht Arbeit, die ich auf einem Rechner erledigt habe, auf einem anderen wiederholen müssen. Ja es soll noch Entwickler geben welche nicht in einer VM entwickeln können, weil die Software direkt mit Hardware reden muss. Auch hasse ich Anleitungen der Art „du musst das BunteTeilMitGrünenTopfernInMindestenVersionSchießm ichtotAberNichtVersionLachnichtAuchNichtWeinnichtU ndSchonGarnichtIstmiregalAberAusDemLilaZweigWelche DasRotWeiseTeilInVersionKennichnichtMitDenBlauenTr opfenAberOhneRotePunkteMit3tenBis17tenBuchstabenGr oßAber7tenBis15tenKleinUnd9tenUnd11tenGroßBenötigt installieren“. (Ps: Der Name ist wohl etwas lang und wurde automatisch mit Freizeichen versehen. Komisch Wörter der Länge bis 2GB sollten doch eigentlich möglich sein)
Das musste jetzt mal raus.
oder eher gar nicht mehr drauf zugreifen, wie schon in den letzten Jahren.
Leider kann ich darauf nicht verzichten, da in dem Projekt mehrfach Gebrauch von der JVCL gemacht wird.
Hat noch jemand einen Tipp wie man das mit
SVN-Mitteln hinbekommt?
Vielen Dank, einbeliebigername.