[offtopic] Github

[svoop]

Hallo Devs

Ich weiss, die Antwort lautet wahrscheinlich "vergiss es", aber fragen kann man ja troztdem:

Gibt es eine Chance, Freetz von Subversion auf Git (bzw. Github) zu migrieren? Das Beisteuern von Code wäre dann erheblich vereinfacht, fork/pull statt Patches schieben.

Beispiel: Statt mehrere Treees zu führen (z.B. einen für das auf der Box benutzte Freetz und einen für die Arbeit an netatalk - http://www.ip-phone-forum.de/showthread.php?t=209224 - könnte ich alles in einem Tree haben und die verschiedenen Varianten branchen. Echte Devs, die viele Baustellen haben, könnten davon noch erheblich mehr profitieren.

Nur so ne Idee

 

[er13]

git-svn sei Dir ans Herz gelegt

 

[svoop]

Ich habe kein Problem mit SVN, für einige Kunden arbeite ich damit und ich gehöre nicht zu den Leuten, die auf einem "gitlike" SVN Client bestehen. Ich dachte mehr an die Arbeit an Freetz überhaupt.

Wäre Freetz auf Github versioniert, gäbe es aber eine Reihe von Vorteilen, ein Beispiel: Ich erstelle einen Fork für netatalk und andere forken meinen Fork, um bei der Entwicklung zu helfen. Deren Codebeiträge kann ich dann quasi stellvertretend pullen, bis mein Fork komplett ist. Erst dann mache ich einen Pull Request und (falls nichts dagegen spricht), können die Freetz Devs netatalk einfach mergen. Ich brauche dabei keinerlei Schreibrechte auf dem "Freetz-Mutterrepository". Will heissen: Leute wie ich können mitmachen, ohne dass die Freetz Devs Schreibrechte vergeben oder Patches herumgeschoben werden müssen.

Freetz ist von der Art her ein ähnliches Projekt wie der Linux Kernel und dafür ist Git IMHO besser geeignet als SVN. Und Github ist ein sehr benutzerfreundlicher (und für OO-Projekte kostenloser) Hoster.

Für die Migration gibt es auch Helfer. Das Repository selbst kann man einfach migrieren, um Issues zu migrieren gibt es Helferlein:

https://github.com/davglass/trac2issues

Für das Wiki gibt es auch ein Script, die History ginge dabei aber verloren.

Aber eben, nur eine Idee. Wenn die Freetz Devs eine Affinität zu SVN haben, dann kann ich das verstehen - auch wenn die Vorteile von Github auf der Hand liegen.

 

[RalfFriedl]

Dann mal eine praktische Frage zu git: Wie macht man es am besten, wenn man in zwei (oder mehreren) Trees parallel und unabhängig von einander etwas machen will.
Bisher bin ich auf folgende Möglichkeiten gekommen:
- Ich setze GIT_DIR auf ein konkretes Verzeichnis. Damit habe ich aber das Problem, daß in diesem Repository immer ein konkreter Branch ausgewählt ist, was dann für den zweiten Tree nicht paßt.
- Ich kopiere das Repository mit clone. Damit habe ich aber den Platz-Verbrauch verdoppelt, und der Vorteil gegenüber zwei SVN-Checkouts erschließt sich mir auch nicht.
Gibt es besser Möglichkeiten?

 

[svoop]

Zwei Clones würden gehen, sind aber nicht die beste Idee. Bei "meinen" Projekte machen wir das wie folgt:

Was du Trees nennst sind Branches. Jeder Tree ist also ein Branch. Einen solchen erstellen ist ein Einzeiler:

git branch netatalk

Wenn ich dann an mehreren Branches "parallel" arbeite, dann wechsle ich zwischen den Branches hin und her - so wie ich mit "cd" zwischen zwei separaten Clones wechseln würde:

git checkout master
git checkout netatalk

Wenn du natürlich wirklich parallel (also z.B. zwei Editoren offen) arbeiten möchtest, dann musst du schon zwei Mal clonen und dann im einen auf dem master Branch und im anderen auf dem netatalk Branch arbeiten. So arbeite ich persönlich aber sehr selten und wenn es mal passiert, dann clone ich nur für die Zeit halt ein zweites Mal. Das Clonen von Git ist erheblich schneller als das Checkout von SVN und bei den heutigen Festplatten-Kapazitäten ist die Verdopplung eher kein Argument mehr.

Mit SVN musst du für echte Parallelarbeit auch zwei Checkouts machen. Ich glaube nicht, dass es ein VCS gibt, bei dem das nicht nötig ist. Die Vorteile von Git liegen eher dabei, dass das Branchen/Mergen sehr einfach ist und man bei verteilten Projekten die Änderungen nicht in ein zentrales Repo schreibt (und dafür Schreibrechte braucht), sondern die Owner des zentralen Repos anfragt, die Änderungen einzumischen - ohne dass das Erstellen von Patches nötig wird. Github vereinfacht diese Schritte immens.

 

[olistudent]

Wenn die Freetz Devs eine Affinität zu SVN haben, dann kann ich das verstehen - auch wenn die Vorteile von Github auf der Hand liegen.

Das Problem an einer Migration von svn nach git ist ja nicht die Migration an sich. Trac mit Subversion läuft zuverlässig. Wie das mit einem git Plugin für Trac aussieht (ja, es gibt eins) weiß ich nicht.
Ich hab keine Ahnung von git. Die Einarbeitung würde wohl einige Zeit in Anspruch nehmen. Dann braucht man neue Tools zum Commiten. Git-Plugin für Eclipse, TortoiseGIT...
Und ich bin dann ja auch nicht der Einzige der sich da einarbeiten muss.

Gruß
Oliver

edit: Nicht desto trotz bin ich gerade dabei ein git repo auf freetz.org zu clonen.

 

[RalfFriedl]

Was du Trees nennst sind Branches.

Ich meinte mit Tree das Verzeichnis, das zum aktuellen Stand des jeweiligen Branch gehört. Wenn ich das richtig sehe, ist das die git-Terminiologie für ein Verzeichnis, was ich nicht ganz glücklich finde, eben weil sonst eher Tree und Branch zusammen gehören.

Wenn ich dann an mehreren Branches "parallel" arbeite, dann wechsle ich zwischen den Branches hin und her - so wie ich mit "cd" zwischen zwei separaten Clones wechseln würde:

git checkout master
git checkout netatalk

Und was passiert mit Änderungen, die noch nicht commited sind?
Außerdem möchte ich, daß alle Dateien aus beiden Branches auf der Platte bleiben. Bei Freetz wird die toolchain neu erstellt und ähnliches, was dann doch lange dauert.

Wir sollten außerdem bezüglich Freetz unterscheiden zwischen Git und Github.

 

[hermann72pb]

@Oliver: Sei aber bitte vorsichtig! Bevor du da freetz.org durch deine Experimente zerschießt...
Klar, gibt es vermutlich viele Vorteile GIT zu benutzen. Du bist aber bis jetzt der einzige hier, svoop, der das wirklich will. Wie Oliver schon sagt, es läuft mit svn, alle haben sich mehr oder weniger darauf eingestellt und sich damit außeinander gesetzt, die ganzen Wiki-Artikel und IPPF-Threads beinhalten Beispiele, wie man dies oder das auscheckt/eincheckt. Eine Umstellung wird seeehr viel Aufwand bedeuten und uns allen letztendlich viel Zeit kosten. Diese Zeit können wir lieber damit verbringen was besseres für FREETZ zu machen, als uns mit dem GIT auseinanderzusetzen.

MfG

 

[svoop]

Du bist aber bis jetzt der einzige hier, svoop, der das wirklich will.

Ich "will" nicht Git, meine Frage war nur, ob Git eine Chance hätte, denn - einmal eingeführt - würde es eine Reihe Vorteile bieten, besonders wenn von Github gehostet. Klar bedeutet eine Umstellung Aufwand, aber nach der Umstellung könnten mehr Leute an Freetz mitwirken, ohne dass die Gruppe der Devs aufgeblasen wird. Wie gross der Aufwand wäre, kann ich nicht wissen (bin ja kein Dev), daher überhaupt meine Frage.

Und was passiert mit Änderungen, die noch nicht commited sind?

Bei Git werden nicht committete Modifikationen bei einem Wechsel des Branches auf den neu gewählten Branch angewendet. Wenn du das nicht möchtest, kannst du alle nicht committeten Modifikationen stashen (aka: in eine Art Zwischenablage legen). Um also ohne Commits die Branches zu wechseln, machst du: Stashen -> Branch wechseln -> (...) -> Branch zurückwechseln -> Stash anwenden. Wenn das zu popelig ist, könntest du auch einen Hook schreiben, der automatisch einen Stash erstellt/anwendet, wenn es nicht committete Modifikationen gibt.

Außerdem möchte ich, daß alle Dateien aus beiden Branches auf der Platte bleiben. Bei Freetz wird die toolchain neu erstellt und ähnliches, was dann doch lange dauert.

Die Toolchain ist ein einem eigenen Verzeichnis. Wenn du das in .gitignore ignorierst, wird es quasi von allen Branches benutzt.

Ich hab keine Ahnung von git. Die Einarbeitung würde wohl einige Zeit in Anspruch nehmen.

Im Alltag brauche ich immer dieselben 10 Kommandos, das ist schnell gelernt. Plugins gibt es für alle gängigen IDEs. Mich hat es damals auch genervt, wegen einem OO-Projekt Git lernen zu müssen - aber selten hat sich der Aufwand so gelohnt, denn ...

Wir sollten außerdem bezüglich Freetz unterscheiden zwischen Git und Github.

... gerade mit Github gehostet, muss man sich um viel Kleinkram nicht kümmern. Bugtracker, Wiki, Gist - ist alles da, gut integriert und mit Webhooks ausgestattet. Für ein Projekt wie Freetz macht es IMHO keinen Sinn, einen eigenen Git-Server zu fahren, das wäre dann wirklich zuviel Aufwand. Und der grosse Vorteil, dass Nicht-Devs mit Fork und Pull Request mitarbeiten können, ist mit einem eigenen Server nicht so trivial.

Ich habe sicher schon bei einem guten Dutzend Rubygems Code beigesteuert, weil das mit Github so einfach ist. Hätten die Autoren Patches verlangt, hätte ich wegen dem Mehraufwand nur für mich gewurstelt. Shame on me, vielleicht, bin aber sicher nicht der einzige.

 

[Silent-Tears]

Nun, der eigene Server ist allerdings da, wieso also den Code sonstwohin packen? Ich mein, dann kann man sich auch auf google groups und code umschwenken oder sonst etwas, ebenso wie diverse andere Hoster von irgendwelchen Repositories. Btw: Mercurial ist auch noch ein Versionsverwaltungssystem, was man schätzen kann, wenn man denn mag. Und nun?

 

[svoop]

Nun, der eigene Server ist allerdings da, wieso also den Code sonstwohin packen?

Hauptsächlich sehe ich zwei Gründe:

Wenn Nicht-Devs mitarbeiten wollen, dann bedeutet das bei SVN entweder Schreibzugriff zu erhalten (was kaum jemand will) oder das Patches hin- und hergeschoben werden. Warum ein VCS, wenn man dann doch mit Patches hantiert? Mit Git bzw. Github kann jeder wie gesagt forken und die Devs können aus den Forks mergen, was fertig ist, funktioniert, gefällt. Patches ade.

Ein eigener Server muss gewartet werden. Zum Beispiel Trac selber aktuell halten ist ein fortlaufender Aufwand, den man betreiben muss, um nicht irgendwann zu den traurigen Projekten gehören, auf deren Webseite es heisst: "We've been hacked, our Repo is gone, it'll take a few weeks to rebuild and rewrite things." Eine andere Endstation sind HD-Crashes und fehlerhafte Backups.

Einen eigenen Server zu haben bedeutet nicht, dass er für alles benutzt werden muss, ein IRCd ist ja auch nicht auf der Maschine.

Wäre Freetz ein Ruby-Projekt, würde ich die freiwerdende Rechenpower für Continuous Testing benutzen, also statt dass bei jedem Dev die Tests lokal laufen, macht das der Server. Vielleicht gibt es ja für Freetz auch Möglichkeiten, die Hardware anders zu nutzen.

Mercurial kenne ich von einem einzigen Projekt und es ist derart langsam, dass es weder mit SVN noch Git verglichen werden kann. Ähnlich sieht der Vergleich zwischen Google Code und Github aus, Github ist viel ausgereifter.

 

[hermann72pb]

Soviele Schreibmutige haben wir hier aber nicht, svoop. Etwas auf dem Server zu testen kann man auch kaum machen, da wir laute Fritz!Boxen haben, die sich zudem noch unterschiedlich verhalten. Da kommt man nicht drumherum, dass jemand die Sachen auf seiner Box testet. Und wenn ich mal dazu komme, was für FREETZ zu entwickeln, dann macht es für mich nicht viel aus einmal auszuchecken, Daten reinzukopieren und dann einmalig "svn diff" durchzuführen. Und wenn ich es als patch irgendwo im Ticket poste, dann können sich es devs anschauen, Testlüstige einspielen usw. Es funktioniert doch wunderbar! Willst du uns allen zumuten, dass wir uns jetzt einfach umstellen, wobei mir der Sinn der Umstellung bis jetzt nicht klar ist.
Und dass Silent-Tears und olistudent unseren Server mit trac ordentlich verwalten, davon gehe ich fest aus. Die von dir beschriebenen Szenarios kann ich mir bei uns schlecht vorstellen.

MfG

 

[Silent-Tears]

Hei, der Server ist ok. Es ist immerhin meiner und der wird kontinuierlich gepflegt. ^^ Gut, github wird mehr Ressourcen haben, und sicherlich auch mehr Rechenleistung und sonst etwas, aber irgendwo wird der Haken sein, und ich weiß noch nicht welcher. Immerhin muß der Server und die Leistung ja irgendwoherkommen, oder? ^^
Es ist außerdem kein Problem, trac auf git umzustellen, wenn ich das richtig sehe, oder gar beides anzubieten. Wieso auch nicht?

 

[olistudent]

@svoop
Wie war das mit git und leeren Verzeichnissen? Muss man da was beachten?

Gruß
Oliver

 

[RalfFriedl]

Der Kommentar bei git-svn liest sich so, als würde git keine leeren Verzeichnisse unterstützen.

 

[svoop]

Wie war das mit git und leeren Verzeichnissen? Muss man da was beachten?

Git nimmt leere Verzeichnisse nicht in den Index auf. Wenn du ein leeres Verzeichnis erzwingen willst, dann erzeuge darin z.B. eine .keep Datei.

 

[svoop]

Es funktioniert doch wunderbar! Willst du uns allen zumuten, dass wir uns jetzt einfach umstellen, wobei mir der Sinn der Umstellung bis jetzt nicht klar ist.

Statt mit Patches könnte man mit Branches (Devs) und Fork/Pullrequests (Contributers alias Nicht-Devs) arbeiten. Wenn sich Arbeiten in die Quere kommen, kann man die mit Git die Kollisionen auflösen.

Für Contributer würde es einfacher, am Projekt aktiv mit Code teilzunehmen. Wenn ihr aber nicht glaubt, dass es solche Contributer gibt, dann macht es wohl keinen Sinn. Genügend interessanten Code, den man auf die FB portieren könnte, wäre allerdings schon noch vorhanden.

Zurück zur ursprünglichen Frage: Wenn alles so bleibt wie es ist, kein Problem, war ja nur eine Idee. Wenn ihr andererseits Git ernsthaft kennenlernen wollt um zu sehen, ob es doch etwas für Freetz wäre, dann fragt einfach drauflos. (Morgen bin ich allerdings offline.)

PS: Ich zweifle nicht daran, dass der Trac-Server gut gewartet ist. Weniger Arbeit ist ein externer Hoster aber auf jeden Fall. Und Github ist (wie andere Hoster) für OO-Projekte sogar kostenlos.

 

[er13]

edit: Nicht desto trotz bin ich gerade dabei ein git repo auf freetz.org zu clonen.

Haben wir für die Zeit Commit-Freeze oder so was ;-)

r6141 hat extrem lang gedauert und hat am Ende folgendes ausgespuckt:

Warning: post-commit hook failed (exit code 128) with output:
/var/www/servers/trac.freetz.org/trac/plugins/TracRevtreePlugin-0.6.3dev_r0-py2.6.egg/revtree/svgview.py:17: DeprecationWarning: the md5 module is deprecated; use hashlib instead
/var/www/servers/trac.freetz.org/trac/plugins/TracDownloads-0.3-py2.6.egg/tracdownloads/tags.py:3: DeprecationWarning: the sets module is deprecated
cd: 44: can't cd to /var/git/www.freetz.org
fatal: Not a git repository (or any of the parent directories): .git
Already at toplevel, but .git not found
 at /usr/local/libexec/git-core/git-svn line 276

 

[hermann72pb]

Genau das hatte ich befürchtet: Never Change a Running System!

MfG

 

[svoop]

Genau das hatte ich befürchtet: Never Change a Running System!

... sagt der Fritzbox-Modder