Community-Repository auf GitHub

[mhier]

In einem anderen Thread kam die Idee auf, ein gemeinsames Firmware-Repository auf GitHub anzulegen, um das Teilen der Modifikationen unter den Entwicklern zu vereinfachen. Ich habe schon mal eine Organisation angelegt:
https://github.com/RF1000community

Wer Interesse an der Mitwirkung hat, schreibt mir bitte einfach kurz per PM seinen Benutzernamen von GitHub, dann füge ich euch hinzu. Ich habe noch kein Repository angelegt, da möchte ich vorher kurz die Struktur diskutieren:

Meine Idee wäre, die Verzeichnis-Struktur des Original-Conrad-Repositories nicht zu übernehmen. Dort gibt es zwei Unterverzeichnisse RF1000 und RF2000, die bis auf eine Zeile in der Konfigurations-Datei absolut identisch sind. Das ist nett für die Benutzer, die gleich die richtige Version bekommen, aber letzlich ein Albtraum für uns Entwickler. Ich würde daher also nur eines der beiden Verzeichnisse übernehmen. Die komplette Verzeichnis-Ebene ist letzlich überflüssig, also würde das "Repetier"-Verzeichnis direkt an oberster Ebene stehen (also schon noch als Unterverzeichnis).

Um Änderungen von "Upstream" (also Conrad) einfach übernehmen zu können, legen wir einen Branch "official_upstream" an, der eine exakte Kopie des "development"-Branches vom Conrad-Repository ist, nur mit entsprechend angepasster Verzeichnis-Struktur. Diesen Branch können wir dann einfach in unseren echten Development-Branch mergen. Um Verwirrungen zu vermeiden, würde ich diesen Branch nicht "master" nennen, obwohl das die übliche Bezeichnung wäre (leider ist sie aber von Conrad für die stabile Version belegt wurden). Daher würde vorschlagen, dass unser echter Development-Branch "community_development" heißt. Es steht natürlich jedem Entwickler frei, dann weitere Branches anzulegen, sollte das mal sinnvoll sein (bei größeren Änderungen z.B., wo man in Ruhe auch mal was kaputt machen möchte ).

Was meint ihr? Gibt es noch andere Ideen, bessere Vorschläge etc?

[Nibbels]

Ich hab da schon rumgetestet.

- Einfach Repetier_RF1000.ino und Repetier_RF2000.ino machen geht nicht, weil die benennung dieser Datei mit dem überliegenden Ordnernamen gleich sein muss.
- Jeden User zwingen, die Config zu ändern. Halte ich für blöd, das blickt kein Anfänger. Ich weiß noch, wie ich herausfinden musste, was ein Branch ist.
- Man könnte zwei Dateien wie compile_RF1000.h und compile_RF2000.h anlegen und per DEFINE und IFDEF erzwingen, dass eine gelöscht wird? Notfalls als Fehler ausgeben.
- Es einfach so lassen. Ich ändere meist in der RF2000/Repetier/*, sortiere die Dateien nach Datum und kopiere alles geänderte nach RF1000/Repetier/*. Man darf das nur nicht mit der configuration.h machen.

Ich suche weitere Möglichkeiten, aber so lassen wie gewohnt hilft den meisten Nutzern.

[mhier]

- Jeden User zwingen, die Config zu ändern. Halte ich für blöd, das blickt kein Anfänger. Ich weiß noch, wie ich herausfinden musste, was ein Branch ist.

Um User mach ich mir erstmal keine Gedanken. Ich kann dafür gerne eine Compile-Job einrichten, der immer die neueste Version zum Download als hex-Datei anbietet (jeweils für den RF1000 und den RF2000 natürlich). Damit sind alle User versorgt, die die Konfiguration nicht ändern wollen. Allen anderen kann man auch noch zumuten, diese eine Einstellung zu ändern, denke ich

[rf1k_mjh11]

Martin/mhier,

Dann musst du nur mehr den Usern erklären, wie sie denn eine hex-Datei auf ihren Drucker bringen können (unter Windows, Apple und Linux).

mjh11

[Nibbels]

Ich bleibe irgendwie der Meinung, wir sollten die Ordnerstruktur genau so lassen, wie sie ist.

Mein Vorgehen bisher:
Das komplette Projekt runterladen, entpacken, ändern.
Anschließend die Dateien in den jeweils anderen Ordner kopieren. Dann alle nicht geänderten Dateien am Ende löschen und die geänderten Dateien als inkrementelles Update hochladen.
Ist eigentlich kein sonderlich großes Problem.
Was ich aber nicht weiß, ist, wie du programmierst und arbeitest. Ich eben unter Windows in Notepad++ und ich nutze meist die "Upload Files"-Funktion von Github auf der Website im Browser.

Die Option, diese Hex-Dateien zu nutzen, finde ich gut!
Aber nur als Option für die, die da drin eine Hilfe sehen.

[mhier]

Ich bin strikt gegen Code-Duplikationen, weil man sich damit früher oder später ins Knie schießt... Was machen wir, wenn jemand versehentlich nur eine der Versionen ändert? Welcher Code ist der maßgebliche? Früher oder später wird das schiefgehen, damit habe ich leider genügend Erfahrung... Auch Conrad wird nicht in dieser Verzeichnis-Struktur entwickeln, die haben so viel ich weiß ein internes SVN, von dem aus sie die beiden Versionen ins github hochladen. (EDIT: Und was machen wir bei Konflikten? Die kriegen wir dann ja alle doppelt!)

Hex-Dateien flashen ist nicht sonderlich schwierig, ich denke, es lohnt sich ohnehin, diesen Weg anzubieten. Letzlich ist das sehr viel einfacher und weniger Fehleranfällig als der Weg über die ArduinoIDE. Es gibt diverse GUIs für avrdude, da müssen wir mal ein bisschen was ausprobieren. Ich kann es unter Linux testen und zumindest unter Windows so tun als ob (habe keine Verbindung zwischen Windows-PC und dem Drucker, aber ich kann ja die GUI ausprobieren). Für die Kommandozeile unter Linux habe ich in meinem Github-Repository schon ein einfaches Skript.

Als weitere Alternative könnten wir den Source-Code als ZIP-Datei zum Download anbieten in zwei Versionen für RF1000 und für RF2000. Da könnte man ein kleines Script bauen, was regelmäßig die ZIP-Dateien generiert und eben diese eine Änderung in der Konfiguration vornimmt.

EDIT2: Hier ist eine WindowsGUI für avrdude: https://sourceforge.net/projects/avrdude Kann die vielleicht mal jemand ausprobieren? Die .hex-Datei kann man mit Arduino erzeugen, wenn man einen "Verify" durchführt - das ist das selbe wie Upload nur ohne das eigentliche Hochladen (also es wird einfach alles gebaut). Wo die Datei liegt, verrät einem das Log, wenn das "verbose log" eingeschaltet ist in den Einstellungen. Bei mir liegt die Datei immer irgendwo im Temp-Verzeichnis. In der AVRDude GUI muss man dann den richtigen Chip auswählen (ATMEGA2560) und (mutmaßlich) "arduino" als Programmer und den entsprechenden USB-Port (keine Ahnung wie der heißt, hab ja keine Verbindung).

[Nibbels]

Ok,

Ein Ordner, eine ordendliche Anleitung
+ ZIP-Dateien
+ Hex

Dafür kann ich stimmen

Eine Lösung gegen das versehentlich gleichzeitigem dran arbeiten kann ich aktuell nicht überblicken. Dass ich eine Änderung nur an einem der Drucker vornehme und nicht am anderen fällt durch mein Änderungs-Datum-Kopier-LöschdenRest-System eher weg. Ich bin ziemlich pingelig was den Upload eines Commits angeht.
Sollte aber z.B. Github durch den Desktop-Client sehr viel sicherer bedienbar sein, dann schick mir n Link zur Anleitung

LG

[mhier]

Ok,

Ein Ordner, eine ordendliche Anleitung
+ ZIP-Dateien
+ Hex

Dafür kann ich stimmen

Ok

Eine Lösung gegen das versehentlich gleichzeitigem dran arbeiten kann ich aktuell nicht überblicken.

Wenn man die Verzeichnis-Struktur nicht verhunzt, kümmert sich git darum, dafür ist das ja da

Dass ich eine Änderung nur an einem der Drucker vornehme und nicht am anderen fällt durch mein Änderungs-Datum-Kopier-LöschdenRest-System eher weg. Ich bin ziemlich pingelig was den Upload eines Commits angeht.

Ich benutze normalerweise die "commit early, commit often" Strategie, d.h. ich committe jede kleine Änderung einzeln. Das hat sehr viele Vorteile, u.a. bekommen die Commits dann sinnvollere Log-Messages, Konflikte können besser (d.h. meist automatisch) aufgelöst werden und bei Problemen ist alles viel einfacher nachvollziehbar. Entweder müsste ich dann bei jedem Commit diesen Zirkus machen, oder das andere Verzeichnis bekommt am Ende (vor dem Push) nur einen dicken Commit mit allen Änderungen aus dem anderen Verzeichnis. Dann sind aber viele Vorteile wieder dahin... Hinzu kommen dann noch menschliche Fehler, es kann immer mal passieren, dass man es vergisst, die Versionen anzugleichen. Dann ist schnell das Chaos perfekt, weil ein anderer vielleicht primär im anderen Verzeichnis arbeitet. Der sieht dann erstmal die vergessene Änderung gar nicht und überschreibt sie entweder oder zerschießt die andere Version unbemerkt, weil seine Änderungen nicht dazu passen. Man bräuchte mindestens ein automatisches Script, was einen warnt, wenn die Verzeichnisse divergieren, aber ich finde das alles viel zu kompliziert und fehleranfällig... git ist ein tolles Tool, aber nur wenn man es richtig benutzt

Sollte aber z.B. Github durch den Desktop-Client sehr viel sicherer bedienbar sein, dann schick mir n Link zur Anleitung

Ich benutze für Git keinen speziellen Client sondern einfach Git an der Kommandozeile. Die GUI, von der ich sprach, bedient avrdude, das ist ein Programm zum Hochladen von hex-Dateien in ATMega-MCUs. avrdude (ohne GUI) benutze ich regelmäßig für meine Elektronik-Projekte, aber dann ohne einen Arduino sondern direkt über ein Programmier-Kabel. Ist aber letzlich alles das Gleiche am Ende.

[mhier]

Dann lege ich mal die zentrale Version an. Damit wir nicht gleich mit Konflikten starten, passe ich noch mal meine Version an deine an, so dass sie 100% identisch sind. Ich würde dich bitten, erstmal keine Änderungen an deiner Version vorzunehmen, sonst muss ich das hinterher wieder nachpflegen Falls du noch uncommittete Änderungen hast, kannst du die kurz hochladen bitte?

[Nibbels]

Ok...
Git über Kommandozeile habe ich nie verwendet.

Bei mir stehen keine Änderungen aus
Ready und go.

LG