[Allegro] Experiment mit github statt FTP oder SVN

[Thomas Berger]

Am 14.03.2016 um 14:49 schrieb Bernhard Eversberg:
> Um Bergers Vorschlag versuchsweise zu folgen, wurde ein Repository in "github" 
> angelegt:
>    https://github.com/aresqa/V36
> Zuerst wurden alle Dateien der V35F, ohne die executables, hineingekippt, dann die
> geänderten hinterher, also der Inhalt von newfiles.zip.
> Was man damit nun machen kann, wird Kollege Berger besser erklären können als ich.

Man (z.B. getfiles.flx die Dritte) kann nun auf einzelne Dateien als

https://raw.githubusercontent.com/aresqa/V36/master/zabom.apr

zugreifen. Man kann die Dateien allerdings auch unter der oben
angegebenen Adresse betrachten bzw. als "raw" downloaden, bzw.
ein Zip mit allem generieren lassen. Evtl. nutzt auch jemand
den Issue-Tracker um Probleme zu berichten, das erfordert
aber m.W. einen Account bei GitHub.

Power-User koennen mit einem Git-Client das Repository klonen und
auf diese Weise eigene und zukuenftige "originaere" Aenderungen
automatisiert verwalten, bzw. (die eigenen Aenderungen) in Form
von "Pull Requests" dem Upstream bzw. "Origin" andienen. "GitHub
Desktop" < https://desktop.github.com/ > ist ein speziell auf
GitHub-Integration optimierter Client fuer Windows und Macintosh
(das originaere "git" ist ja ein Kommandozeilen-Programm).
TortoiseGit < https://tortoisegit.org/ > hingegen ist eine
Integration in den Windows-Explorer. Das GitHub-Repository
laesst sich ueberdies unter identischer Adresse
  https://github.com/aresqa/V36
auch als SVN-Repository ansprechen, d.h. wer vorher
https://svn.allegro-c.de/svn/download
ausgecheckt hatte, koennte dies nun mit
 https://github.com/aresqa/V36
tun ("umschalten" ist allerdings nicht ratsam, das Braunschweiger
"download" Repository ist auf Stand Mai 2014, seitdem hat ja
eine mittelschwere Reorganisation der Unterverzeichnisstruktur
stattgefunden)


> Er wird zuerst, dafür kennt und schätzt man ihn, auflisten, was man anders und
> besser hätte machen sollen, was falsch ist und was schlecht, was fehlt und was
> überflüssig, und überhaupt was man sonst noch alles tun und beachten hätte sollen,
> mit allerhand wenn und aber und warum und wozu usw. usf.
> Aber egal, man kann ja auch das ganze leicht wieder entsorgen, wenn es sich
> als Flop entpuppt.

Die Idee speziell hinter GitHub als Repository und Infrastruktur fuer
Git-verwaltete Projekte ist ja gerade, dass es technisch so einfach
sein soll.

Die naechsten Schritte waeren nun Experimente mit der .git-
Konfigurationsdatei, denn ein gaengiges Problem ist, dass
Dateien evtl. mit Unix-Zeilenenden heruntergeladen werden,
die vielleicht besser DOS-Zeilenenden haetten. Meist ist das
egal, ausser a) man will die Datei ausgerechnet mit notepad
betrachten, oder b) es handelt sich um eine .bat-Datei, da
findet Windows 7 manchmal die Sprungmarken nicht ;-)

Git bzw. Versionskontrolle allgemein ist ein /Werkzeug/, m.E.
ist die Lernkurve dafuer inzwischen ziemlich flach, aber
wie bei allen Werkzeugen gibt es Situationen, in denen sie
hilfreich sind und andere, wo nicht. D.h. es entsteht durchaus
ein gewisser Ansporn, seine Arbeitsweise u.U. anzupassen,
so dass das neue Werkzeug seine Wirksamkeit auch entfalten
kann. Insofern koennte das mit dem "abkippen" auf Dauer
ein Problem werden, der Prozess des Synchronisierens des
oder der lokalen Verzeichnisse mit dem bei GitHub aufgesetzten
"origin"-Repository beruht ja eher auf behutsamen "mergen",
d.h. die eigenen Aenderungen sollten lokal "drin" sein und
dann kann ein Abgleich stattfinden: Erst abgleichen und
dann aus einem anderen Verzeichnis pauschal draufkopieren
mit anschliessendem "hochladen" verzeichnet zwar immer
noch akribisch alle Aenderungen und ist damit besser als
nichts, der dadurch abgebildete Workflow gehoert aber
eigentlich nur nach Echternach und nicht ins Internet...

viele Gruesse
Thomas Berger