Welche Dateien in Versionskontrolle sichern

[Marsmännchen]

Hi,

ich bin durch einen anderen Thread auf das Thema Versionskontrolle angefixt worden und fange jetzt mit Git an. Dabei ist mir die Frage gekommen, welche Dateien eines Lazarus-Projektes man versionieren sollte. Alle Dateien einschließlich der jeweiligen *.exe oder nur die Quellcodedateien (*.lpi, *.lpr, *.pas, *.lfm)? Oder bevorzugt ihr eine andere Mischung?

[mse]

Die Aufnahme von Binaries in git Repos sollte die absolute Ausnahme sein. Ich möchte noch auf ".gitignore" hinweisen:
https://git-scm.com/docs/gitignore

[Requion]

Hi Marsmännchen,

ich bin zwar kein Experte aber ich würde sagen das, was du zum entwickeln bzw. (als User) zum kompilieren und benutzen brauchst.
Die Quelltextdateien gehören da mit rein ist ja klar.
Binaries vom Programm würde ich nicht mit rein nehmen. Die werden ja erst aus dem Quelltext erstellt.
Binaries von anderen Programmen die du mitliefern willst sind so eine Sache. Ich persönlich würde die da auch nicht mit reinschmeißen (Aber ich bin kein Experte).
Was m.M.n auch nicht da rein gehört sind Configs mit sensiblen Daten und Configs die vom Programm erzeugt werden (Warum sollte klar sein).

Ich hoffe das hilft dir erstmal etwas weiter.

P.S. Und vergiss nicht das README File...git steht da voll drauf .

[Socke]

Binaries von anderen Programmen die du mitliefern willst sind so eine Sache. Ich persönlich würde die da auch nicht mit reinschmeißen (Aber ich bin kein Experte).

Gerade im industriellen Berech wird die gesamte Build-Chain (IDE, Compiler, Assembler, Linker, Debugger) in einer Versionkontrolle erfasst; Teilweise geht man auch so weit, eine gesamte Virtuelle Maschine, auf der die Compilierung durchgeführt wird, gesichert.
Für kleine Hobby-Projekte ist das aber zu viel; da reicht Quelltext und die vom Programm benötigten Binärdateien (Bilder, Sounds etc.) voll ausreichend.

[mse]

Gerade im industriellen Berech wird die gesamte Build-Chain (IDE, Compiler, Assembler, Linker, Debugger) in einer Versionkontrolle erfasst;

Aber nicht unbedingt für die Laufende Entwicklungsarbeit sondern für Release-Versionen in einem separaten Repository. Exe und Unit-Dateien im Entwickungsrepository machen zu viel "Noise".

[Warf]

Binäry Dateien (z.B. exe) nicht in das Entwicklungsrepo commiten. Versionierungssysteme sind auf Text ausgelegt, und das bedeutet zum einen, binäre dateien sind unglaublich langsam im upload, zum anderen, du kannst bei binären dateien nicht mergen, sondern bekommst jedes mal konflikte.
Außerdem musst du auch keine Konfig dateien wie z.B. die lps commiten, sowie keine Backup Dateien (.bak), ObjectFiles(.o), ppu's, Verwendete Abhängigkeiten (DLL's, Bibliotheken, Packages, etc).

Was du Commiten solltest sind alle Quelltext dateien, Benötigte Resourcen (z.B. Bilder), Projektdateien (lpi) oder Compilescripte (make), Dokumentation, Roadmap, Readme.
Die letzten 3 natürlich nur falls vorhanden.

Außerdem nur Änderungen Commiten die sich zumindest Kompilieren lassen, und ein einheitliches LineEnding verwenden (z.B. verwende ich immer LF, sowohl unter Windows, Linux und OSX), sonst hast du nach jedem Commit mit von einem anderen Rechner nur noch konflikte.

Diese Dinge sind zwar größten Teils für Teamarbeit wichtig, aber gewöhn es dir am besten schon gar nicht falsch an und mach es auch so für allein-projekte.

[Socke]

Gerade im industriellen Berech wird die gesamte Build-Chain (IDE, Compiler, Assembler, Linker, Debugger) in einer Versionkontrolle erfasst;

Aber nicht unbedingt für die Laufende Entwicklungsarbeit sondern für Release-Versionen in einem separaten Repository. Exe und Unit-Dateien im Entwickungsrepository machen zu viel "Noise".

Inwiefern sind Exe- und Unit-Dateien in der Build-Chain enthalten?

[Requion]

und ein einheitliches LineEnding verwenden

Das ist sehr wichtig. In einer ehemaligen Firma hatten wir deshalb mal nen ganzen Tag zu tun das in Ordnung zu bringen (was aber auch daran lag das es ein paar Entwickler mehr waren).
Aber auch bei mir privat muss ich darauf achten, weil ich immer mal zwischen Win und Linux wechsel.

[marcov]

Gerade im industriellen Berech wird die gesamte Build-Chain (IDE, Compiler, Assembler, Linker, Debugger) in einer Versionkontrolle erfasst;

Aber nicht unbedingt für die Laufende Entwicklungsarbeit sondern für Release-Versionen in einem separaten Repository. Exe und Unit-Dateien im Entwickungsrepository machen zu viel "Noise".

Ja. Was Socke sagt passiert, sicher, und ich mache es auch, aber nur ausnahmsweise. Zb man macht eine speziell Binär für einen (gross-) Kunden, und man weißt das man möglich nach zehn Jahre da noch Modifikationen mit minimaler Risiko (denke an Dinge als Textformat der Export ändern, neuen Firmennamen oder so)

Aber das wird ganz schon nicht mehr zu verwalten. Virtueller Maschinen kann man vielleicht in zehn Jahren überhaupt nicht mehr ans drehen bekommen, also das ist nur fuer kurzfristiger Support.

[marcov]

Binäry Dateien (z.B. exe) nicht in das Entwicklungsrepo commiten. Versionierungssysteme sind auf Text ausgelegt, und das bedeutet zum einen, binäre dateien sind unglaublich langsam im upload, zum anderen, du kannst bei binären dateien nicht mergen, sondern bekommst jedes mal konflikte.
Außerdem musst du auch keine Konfig dateien wie z.B. die lps commiten, sowie keine Backup Dateien (.bak), ObjectFiles(.o), ppu's, Verwendete Abhängigkeiten (DLL's, Bibliotheken, Packages, etc).

Und EXEs systematisch eintragen macht backups groß und langsam.

Was du Commiten solltest sind alle Quelltext dateien, Benötigte Resourcen (z.B. Bilder), Projektdateien (lpi) oder Compilescripte (make), Dokumentation, Roadmap, Readme.

Zusätzlich ausgelieferten binäre Dateien (EXE oder JPG grosser als ein Icon usw) trage ich in ein separates Repo ein. Das mutiert weniger, ist also nicht so einen Backup aufwand (*)

Aber backups (und dann liebst auch Offsite) sind mindestens so wichtig als solcher Quatsch.

Unsere SVN server war auf RAID gespeichert, aber das hilft nicht wenn die den Server klauen. (fast geklaut, mein Boss kam morgens ins Büro, und der Server stand draußen am Zaun. Diebe sind wahrscheinlich gestört gewesen, und sind schnell über den Zaun geklettert, und haben den Server stehen lassen. Aber die hätten alle RAM geklaut (Idiot, weil RAM war damals relativ billig, und ältere Typen fast wertlos), auch von der Server.

Also Backups immer täglich, und remote. Eben wenn man RAID hat. Eine kleine Backup kann man nach eine raspberry pi mit ein 32GB Stick zu Hause synchronizieren. (für das Leben solcher Stick oder SD Karte ist es aber auch gut den Backup kompact zu halten. Mehrere Tagen Backup auf der Stick halten, und weniger schreiben heißt längere Lebenszeit des Flashmediums)

(*) SVN's hot-backup.py modifiziert um die letze 4 backups jedes Repo zu halten, und das wird dann mit rsync extern gebracht. Nicht mutiert heißt keinen neuen backup)

[Marsmännchen]

Okay, es schält sich eine relativ einheitliche Stoßrichtung heraus. Im wesentlichen geht es um Quellcode, Ressourcen und Doku (ja, auch Readme-Files ). Bei ".gitignore" bin ich in der Dokumentation schon vorbeigekommen . Ich muss auch sagen: dass es in der GIT-Doku ein deutsches Openbook gibt, verdient schon Respekt. Das erleichtert den Einstieg doch sehr. Versionskontrolle ist auch nicht so eine Geheimwissenschaft, wie ich erst dachte. Man muss sich halt einfummeln.

Nachdem ich jetzt meinen Taschenrechner fast fertig habe (ich bin noch am entwanzen) werde ich mich jetzt auf das weltbewegende Entwickeln eines Weckers stürzen... und das mit Versionierung ! Als erstes werde ich heute abend Git installieren und mir ein Remoterepository besorgen. Ich tendiere zu BitBucked.

Danke auch für die Cheats (einheitliches LineEnding - Commit sollte zumindest kompilierfähig sein).

[Marsmännchen]

und ein einheitliches LineEnding verwenden

Das ist sehr wichtig. In einer ehemaligen Firma hatten wir deshalb mal nen ganzen Tag zu tun das in Ordnung zu bringen (was aber auch daran lag das es ein paar Entwickler mehr waren).
Aber auch bei mir privat muss ich darauf achten, weil ich immer mal zwischen Win und Linux wechsel.

Ist zwar OfTopic, aber weil ich grade mal nachgesehen habe: Wie kann ich denn für ein einheitliches LineEnding sorgen? Ich dachte, da gibt's bestimmt einen Schalter in den Lazarus-Options und hab in der Doku gestöbert. Da fand ich das hier:

LineEnding is a constant which contains the current line-ending character. This character is system dependent, and is initialized by the system. It should not be set.

This constant is part of a set of constants that describe the OS characteristics. These constants should be used instead of hardcoding OS characteristics

[mse]

Ist zwar OfTopic, aber weil ich grade mal nachgesehen habe: Wie kann ich denn für ein einheitliches LineEnding sorgen?

Für die zur aktuellen Plattform passenden Zeilenenden in den ausgecheckten Quellcode Dateien sorgen sowohl SVN als auch git.
https://git-scm.com/docs/git-config

core.eol
Sets the line ending type to use in the working directory for files that have the text property set. Alternatives are lf, crlf and native, which uses the platform’s native line ending. The default value is native. See gitattributes[5] for more information on end-of-line conversion.

[Marsmännchen]

Danke

Edit: Bei der Installation wurde ich von Git gefragt, wie ich es mit dem LineEnding halten möchte. Ich habe die Defaultoption gewählt (bei commit konvertiert Git nach LF, bei checkout konvertiert es nach dem Defaultending des jeweiligen Betriebssystems). Ich hoffe, das ist jetzt richtig. Na, ich werde es merken.

[marcov]

und ein einheitliches LineEnding verwenden

Das ist sehr wichtig. In einer ehemaligen Firma hatten wir deshalb mal nen ganzen Tag zu tun das in Ordnung zu bringen (was aber auch daran lag das es ein paar Entwickler mehr waren).
Aber auch bei mir privat muss ich darauf achten, weil ich immer mal zwischen Win und Linux wechsel.

Ist zwar OfTopic, aber weil ich grade mal nachgesehen habe: Wie kann ich denn für ein einheitliches LineEnding sorgen?

Das konnte lange Zeit nicht mit GIT. In SVN ist ein Repo in eine gewisse Line-endung(also, es ist Serverside definiert). mit GIT hängt alles ab von der korrekten Konfiguration der Client. Eine falsche Client Konfiguration kann der Server inkonsistent machen. Line-ende-handlung waren damals eine der Hauptgründe um FPC von CVS auf SVN um zu stellen.

GIT Advocatisten wie Graeme sagen das es in letzter Zeit auch gelöst ist für GIT, aber ich habe das noch nicht kontrolliert.

Ich dachte, da gibt's bestimmt einen Schalter in den Lazarus-Options und hab in der Doku gestöbert. Da fand ich das hier:

LineEnding is a constant which contains the current line-ending character. This character is system dependent, and is initialized by the system. It should not be set.

Lazarus muss das nicht überwachen. GIT soll das tun, und es soll verweigern oder konvertieren wenn nötig.