Skip to content

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. :-)

Trackbacks

Netz - Rettung - Recht am : Git-Repositories mit gitosis und gitweb (Debian Lenny)

Vorschau anzeigen
Wie ich bereits schrieb, habe ich mich in den letzten Tagen etwas näher mit dem Versionskontrollsystem (VCS, oder auch SCM für “Source-Code-Management”) git beschäftigt. Das macht natürlich nur bedingt Spaß - und Sinn -, wenn die Repositorie

Netz - Rettung - Recht am : control-archive 1.3.0: Patches akzeptiert

Vorschau anzeigen
Heute hat Russ control-archive 1.3.0 releast, und die von mir letzte Woche submitteten Patches sind alle aufgenommen worden. Sehr schön! Außerdem wurde das Paket so weit aufgebohrt, daß auch Vermerke zu Hierarchien und entsprechende Sonderfälle jetzt au

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

flawed am :

flawed

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 :

Thomas Hochstein

QUOTE:
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.

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 :

flawed

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 :

Thomas Hochstein

QUOTE:
Nach meinem heutigen Verständnis sehe ich zwei Gebiete, wo DVCSe (= hg oder git) richtig Spaß machen können: […]

Wie gesagt, wo aus meiner Sicht als Allein"entwickler" die Vorteile liegen, plane ich dieser Tage noch zu beschreiben. :-)

QUOTE:
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.

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.

QUOTE:
Multiuser git-over-SSH mit gitosis, wie Du es machst, ist mir nicht ganz so sympathisch.

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

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen