Hallo,

jetzt habe ich auch mal ein Problem. Ich will bei einem Kunden unteranderem die JCL und JVCL aktualisieren. Beide liegen jetzt auf github (https://github.com/project-jedi). Zu Dokumentationszwecken habe ich erst mal die Version gesucht die gerade beim Kunden im Einsatz ist. Diese habe ich glaube auch gefunden.

Aber beim Vergleich ist mir aufgefallen, dass beim auschecken von github mit TortoiseSVN (1.9.4, Build 27285 - 64 Bit) jetzt in vielen Dateien (nicht bei allen) $0A fürs EOL benutzt wird, anstatt wie Windows üblich $0D$0A. Tante Google verweist als Lösung immer auf das Property svn:eol-style, welches aber bei keiner Datei in keiner Revision gesetzt ist. Es ist überhaupt kein Property vorhanden, sollte aber zumindes svn:mime-type=application/octet-stream für alle .exe gesetzt sein.

Wie kann ich dem SVN beibringen das mit den richtigen Enterzeichen auszuchecken?

einbeliebigername.

https://help.github.com/articles/dea...-line-endings/

Hallo,

Zitat von Stevie:

https://help.github.com/articles/dea...-line-endings/

Wie soll mir das jetzt weiterhelfen? Dort geht es scheinbar nur um git. Ich habe aber einen SVN-Client.

Vieleicht hätte ich das noch erwähnen sollen, dass beim Kundne ein SVN gibt und dort soll an einer Stelle z.b. ein "svn:externals=https://github.com/project-jedi/jcl/trunk/jcl@9608 Jcl" gemacht werden.

einbeliebigername.

Das Repo ist nach wie vor ein Git repo und wird vermutlich mit git svn ausgecheckt.

Meine persönliche Empfehlung ist, ein git Repo auch mit Git zu holen und nicht auf ein svn repo zu konvertieren.

Das interessierte mich jetzt auch. Früher habe ich immer relativ simpel mit svn meine internen und die offiziellen JEDI Sourcen synchron gehalten und ab und zu auch mal was submitted. Aber seit die auf git umgestiegen sind, ist mir der Aufwand zu groß. Wenn ich aber wieder einfach ein svn:external verwenden könnte...

Ich habe gerade versucht, mit

svn co https://github.com/project-jedi/jcl/trunk/jcl

die aktuellen Sourcen zu ziehen. Das hat erstmal geklappt, allerdings haben, wie Du schon festgestellt hast, viele Dateien LF als Zeilenumbruch statt CRLF.
Man kann natürlich die EOL-Property setzen, nur müsste man diese Änderung committen, was ziemlich sinnfrei ist, schließlich will ich ja nichts committen sondern nur die aktuellen Sourcen verwenden.

Bleibt wohl doch wieder nur git, oder eher gar nicht mehr drauf zugreifen, wie schon in den letzten Jahren.

Hallo,

Zitat von Stevie:

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.

Zitat von dummzeuch:

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.

Ich kann mich jetzt nicht erinnern, dass ich beim Checkout von Github über TortoiseSVN ein Problem mit den Zeilenumbrüchen hatte.
> 'nen einfacher Checkout auf https://github.com/project-jedi/jcl/trunk/jcl

Nach der Beschreibung https://help.github.com/articles/sup...rsion-clients/ hatte ich es Visuell über TortoiseSVN nicht hinbekommen und war beim Punkt 5 hängen geblieben, so weit ich mich erinner.



Alternativ, statt 'nem EXTERNAL ein INTERNAL
mit GIT runterladen und das GIT-Repo ins SVN einchecken ... ab und an dann 'nen GIT-Sync, gefolgt von einem SVN-Commit