Patches für control-archive
Ich hatte ja bereits darüber berichtet, daß mich der simple Wunsch, meinen Newsserver etwas aufzuräumen, über den Umweg über die List of Usenet public managed hierarchies auf eine mehrwöchige Tour durch die deutschsprachigen Regionalhierarchien geschickt, zum Aufbau von De-Regio und zur Installation von git gebracht hatte. Mittlerweile habe ich mich hinreichend sortiert, um für das control-archive-Paket eine ganze Reihe von Änderungen einzureichen, die ich nun in Form von git-Patches gebracht und per Mail an den Maintainer verschickt habe; mehr oder weniger das erste Mal, daß ich auf diese Weise irgendwo einen Beitrag leiste. Mal schauen, ob die Patches akzeptiert werden.
Mit git muß ich mich aber definitiv noch näher beschäftigen, sofern es da auch etwas unter Windows gibt; das scheint mir endlich mal ein VCS zu sein, mit dem ich klarkomme. 
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
flawed am :
Interessant, ich tue mich mit dem Verständnis der Konzepte der neuen Generation von Versionskontrollsystemen (git, Mercurial) noch immer schwer.
Ich frage mich, ob meine Erfahrung mit der vorherigen Generation von Versionskontrollsystemen (Subversion, CVS) mir da im Weg steht.
Thomas Hochstein am :
Ich frage mich, ob meine Erfahrung mit der vorherigen Generation von Versionskontrollsystemen (Subversion, CVS) mir da im Weg steht.
Das könnte ich mir gut vorstellen; etliches funktioniert bei DVCS eben ganz anders als bei VCS mit einem zentralen Repository. Mir gefällt git - aus meinem Blickwinkel des im wesentlichen Allein"entwicklers" - aus einer Vielzahl von Gründen - die vermutlich auch für die anderen neueren VCS zutreffen -, und nach dem, was ich gelesen habe, bietet es auch bei der Zusammenarbeit mehrerer und vieler erhebliche Vorteile (die Kernelentwicklung war ja auch der ursprüngliche Grund für die Entwicklung von git).
Ich will bei nächster Gelegenheit auch noch etwas dazu schreiben, was mir - bisher - an git gefällt.
flawed am :
Ich habe mich die Tage nun mehr mit DVCS beschäftigt, und verstehe die Sache nun etwas besser. Joel Spolsky’s Tutorial auf http://hginit.com/ hat mir dabei sehr geholfen. (für Mercurial, aber die Konzepte sollen ja bei git sehr ähnlich sein.)
Nach meinem heutigen Verständnis sehe ich zwei Gebiete, wo DVCSe (= hg oder git) richtig Spaß machen können:
da wäre zunächst der ganze kleine Rahmen: ich will für mich ganz alleine etwas versionieren? hg init (bzw. git init) aufs Verzeichnis, und los gehts. Kein Kopfzerbrechen, wo das Repository hin soll, wie es aussieht, usw. Dann noch Repository auf einen Server clonen, und man bekommt Backup quasi geschenkt mit hg push.
auf der anderen Seite natürlich "richtige" Softwareentwicklung: wenn branching+merging wirklich so gut funktioniert wie beworben, hätte es mein früheres Leben als SW-Entwickler so viel leichter gemacht.
Dazwischen gibt es dann einen Bereich, wo ich aber leichte für SVN sehe, und das ist bei kleinen in kleinen Teams, z.B. kollaborativ an einem Journalartikel schreiben oder so. Da will ich meine Änderungen oft schnell dem Team sichtbar machen, und habe immer hg commit + hg push und auf der anderen Seite den Dreisprung pull+update+merge. Das ist dann IMHO ein bisschen viel, und erhöht auch den Schulungsaufwand der User/Kollaborationspartner, denke ich. Würde mich interessieren, ob es Leute gibt, die in solchen Szenarien von-0-auf-DVCS schulen, und wie die das machen.
Was mich gerade noch beschäftigt, ist, wie man - speziell bei Mercurial, aber wohl auch bei git - Server einrichtet, die ein Dutzend Repositories zu Verfügung stellen, und dabei nur eingeschränkte Benutzerkreise für pull oder gar push zulassen. Und natürlich ohne Systemaccounts für jeden Benutzer anzulegen. HTTP-Server-Support scheint mir eher so lala zu sein. Klar github bzw. bitbucket, zeigen, dass es gehen muss, aber zum selbermachen? Sieht auf Anhieb nicht so eingängig aus. Zumindest die Doku ist da bei SVN schon umfangreicher. Multiuser git-over-SSH mit gitosis, wie Du es machst, ist mir nicht ganz so sympathisch.
Thomas Hochstein am :
Wie gesagt, wo aus meiner Sicht als Allein"entwickler" die Vorteile liegen, plane ich dieser Tage noch zu beschreiben.
Das geht, wie ich finde, mit gitosis sehr schön. Wenn man das Webinterface (gitweb) wegläßt oder einen Paßwortschutz daranknüpft und den Zugriff via git-daemon ggf. entsprechend beschränkt, hat man auch kein Problem mit unerwünschten (Lese-)Zugriffen.
Darüber hinaus geht wohl auch git-over-HTTP (Webdav), genau wie bei SVN, siehe dazu bspw. den Eintrag beim Wohnzimmerhostblogger hier in Stuttgart.
Nicht daß wir uns mißverstehen: gitosis nutzt nur einen Systembenutzer, die git-Accounts sind quasi virtuell, werden also nur in gitosis angelegt, nicht als Systembenutzer. Das hätte ja sonst auch keinen Wert.
-thh