Überblick: Versionsverwaltung (SVN & Git)

[easyuser]

Hallo!

Da es zu sehr OffTopic wäre, hier ein eigenes Thema zur Versionierung.

Ich weiß, dass es viele unterschiedliche CVS gibt, aber für mich sind das alles bömische Dörfer.
Ich verwende so gut wie keine Versionierung. Ich weiß dass es - auch bei ein-Mann Projekten - kontraproduktiv ist.
Und ich möchte es in Zukunft ändern. Muss mich damit beschäftigen, deswegen meine Newbie-Fragen.

Ist gar nicht so schwer.
Es gibt zwei Arten von Versionsverwaltung:
"Zentrale Systeme" (CVS, SVN (SubVersioN)) und
"Verteilte Systeme" (praktisch alle anderen OpenSource-Systeme incl. Git).

Heutzutage haben eigentlich nur zwei Systeme noch große Bedeutung: SVN(SubVersioN) und Git. Auf die beschränke ich mich.

Jede IDE die etwas auf sich hält (ob nun Eclipse, PHPDesigner oder wie sie alle heißen) hat eine Integration von SVN & Git.
TortoiseSVN und TortoiseGit ist eine Möglichkeit - aus meiner Sicht aber keine gute. Speicherfressend und Instabil. Sieht nett aus, aber das war es schon. Leider ist es für Einsteiger (unter Windows) die einzige "Klicki-Bunti" Möglichkeit. Ich bevorzuge lieber die Konsole - die paar Befehle sind schnell gelernt. Zudem ist es egal, ob ich mich nun auf meinem lokalen PC oder extern befinde. Für Git bevorzuge ich "msysgit".

Ich will aber Github - weder Git noch SVN!

Berechtigter Einwand. Oft wird hier im Forum Git und Github gleichgesetzt. Es hat aber erst einmal gar nichts miteinander zu tun. So wie Auto und Autogarage.
Ich kann mein Auto irgendwo haben und ich kann eine Autogarage als Wintergarten benutzen, ohne ein Auto zu besitzen.

Github ist die Garage. Hier kann man eine Versionsverwaltung hinterlegen.
Ob das aber nun unter Github, websitebaker.org oder "MyFunnyPC" stattfindet ist schnurz. Github ist halt der größte Dienstleister, kostenlos (mit Einschränkung) und sicher einer der Gründe, wieso sich Git so schnell verbreitet hat.

1. Was soll ich nun für eine Versionsverwaltung nehmen?

Wir wissen: SVN ist zentral, Git dezentral.
Man sollte sich vorher überlegen, was man später will.

- Ich arbeite alleine => Git oder SVN
Es ist schwierig hier einen Kandidaten hervorzuheben.
Gar keiner ist eine Möglichkeit - aber nicht immer gut.
Es ist einfach beruhigender, am Ende des Arbeitstages einen "Commit" zu fahren. Und je nachdem ob er gut war freut man sich, wenn der PC kaputt ist aber die Arbeit nicht. Und wenn der Tag schlecht war, dass man auf den Tag zuvor zurück kann.
Zudem gibt es eine Chronik wo ich Änderungen leicht nachvollziehen kann - Änderungen an Dateien usw. Man muss eben einmal Ordnung ins Chaos bringen.
SVN ist dann gut, wenn man einen zentralen Server bevorzugt.
Git ist dann besser, wenn man sich um einen Server nicht sorgen will (Stichwort: Github. Doch Vorsicht! Auch wenn es nicht nach "Server" aussieht, ist es einer!) Mehr später.

- Ich arbeite mit anderen in einer einzigen, abgeschlossenen Gruppe => SVN
Es ist hier besser, auf die dezentrale Arbeitsweise von Git zu verzichten.
Ein einziger Server der gesichert wird. Kopien wird es nicht geben. Zur Not kann man auch mit SVN klonen (clone).

- Ich arbeite mit anderen an einem OpenSource (alternativ: offenem) Projekt => Git
OpenSource Projekte haben die Angewohnheit, dass man sich auf nichts verlassen kann. Mal geht eine Entwickler, dann kommen fünf, mal ist der Teil der Software wichtig, mal jener. Ungewollte, agile Softwareentwicklung eben.
Um die Arbeit zu beschleuigen, kann man das Projekt von vorneherein in sinnvolle Pakete schnüren (nicht verwechseln mit Java packages!) und diese unabhängig voneinander vorantreiben. Bei WebsiteBaker könnte man z.B. "framework", "admin" und "templates" aufspalten in unabhängige Pakete. Jedes Team hat ihren Server - egal wo - sinnigerweise sogar jedes Teammitglied.

2. Was ist nun SVN (SubVersioN) bzw. Git?

SVN: Ich habe einen Server und Leute, die mitarbeiten. Denken die Leute, sie hätten etwas fertiggestellt (oder den Tag rumgebracht) wird an den Server ein "commit" vollzogen. Mehr gibt's nicht zu sagen - danke für die Aufmerksamkeit.

Git: Ich habe Leute die mitarbeiten, und jeder hat seinen Server. Verschiedene Leute bilden Projekt-Teams (in Git heißt es "branch" - ein Entwicklungszweig), die haben wiederum Server und am Ende hat man einen Master, der eigentlich nichts tut außer das Sammelsurium aus Unter-Projekten in einem darzustellen.

Wenn verschiedene Branches (Projekt-Teams) zusammengelegt werden sollen nennt man das "merging" (in der WB-Sprache gerne auch Fork genannt).

Im Prinzip ist bei Git egal was hinten rauskommt - Hauptsache die Unterprojekte stimmen. Wenn man der Server abraucht oder ein neues Team gegründet wird ist es auch egal.
Also: Ich "commit" zwar bei Git, doch erst einmal bei mir lokal. Ich "push" erst dann meinen "commit" an den Team-Server. Der kann dann wieder vom Projekt-Entwicklungsleiter "commit" werden und an den "Master-Branch" "gepusht.
Alternativ kann man natürlich den Team-Server auch rauslassen - eben ein komplexeres Beispiel, das mit SVN so garantiert nicht klappt.

Man soll aber nicht verschweigen, dass das Mehr an Komplexität auch ein Mehr an Sorgfältigkeit nach sich zieht. Wirft man bei SVN einfach mal alles zum Server, geht das bei Git nicht - weil jeder prinzipiell ein Server ist.

Und noch einmal zu guter Letzt: Nur weil Github so bekannt & beliebt ist, ist es 100% reines Git. Mit allen Tücken.  Auch wenn auf der ersten Blick Git sicherer aussieht als SVN - es kommt aus der Linux Welt. Einmal vollzogen - immer vollzogen. Wer nicht aufpasst, hat seinen Workspace schneller geschrottet, als er bis drei zählen kann. Mit SVN geht das zwar auch, aber deutlich schwerer.

3. Die Praxis - wie lege ich meine Repository (Verzeichnisstruktur) an

Jede Versionsverwaltung braucht ein Startverzeichnis.
SVN: svnadmin create C:\Web\mysvnproject1
Git: git init C:\Web\mygitproject1

So weit, so langweilig. Wenn es hier Probleme gibt bitte melden - gerade der Anfang "warum geht svnadmin nicht?" verhindert jegliches weitere befassen.
Nun habe ich also meine Versionsverwaltung - oder besser: Ein Verzeichnis, wo entweder ein Ordner ".svn" oder ".git". Der führende Punkt ist wichtig - versteckter Ordner unter Unix.

[Bei Interesse To be continued .... ]

[Stefek]

Hallo Michael.

Vielen Dank, dass Du Dir die Zeit genommen hast, das alles aufzuschreiben.
Ehrlich.

Würde es Dir denn gefallen, mit ein paar Leuten ein Pilotprojekt zu machen - auch wenn wir zwei es nur wären - bei dem ein Modul entsteht? Wenn mehr Leute mitmachen wollen, um so besser. Es gibt hier viele Leute, die anders als ich, sich mit der Materie auskennen.

Das Endprodukt für die Community wäre ein voll funktionsfähiges Modul vom Typ Page.
Bei einem solchen Projekt, von jemandem dirigiert, der das Versionssystem kennt, kann man mehr lernen, als nur "trocken" zu lesen - ich verstehe die Worte zwar, doch es fehlt mir die physische Erfahrung.

Wäre der Ablauf einmal verstanden, könnten wir auf diesem Wege mehrere Module parallel auf einen besseren Stand bringen. Unabhängig vom Core-Team (die können mitmachen, als Berater oder auch Aktive, hätten aber kein besonderes Vorrecht an der Entwicklung, denn es wäre ein Community-Projekt).

Ich habe eine Handvoll Module, die auf diese Weise auf einen besseren Stand gebracht werden könnten.
Dazu zählen: Guestbook, Download Gallery (Dietmar war da auch teilweise bei, ich weiß nicht was Stand ist - dazu wäre es halt gut, ein SVN/Git zu haben).
Außerdem habe ich in nich all zu ferner Zukunft vor, einige weitere Module zu verbessern, denn es gibt mitlerweile einige gute neue Methoden im WB, auch eine neue Template-Klasse wird mit WB 2.8.3 eingeführt und somit können wir einige Module auf einen guten Stand bringen.

Ich muss dazu sagen, dass ich nicht immer viel Zeit habe.
Aber da ich sehr viel Spaß am Lernen habe, könnten wir das einmal ins Auge fassen und uns weitere Rahmenbedingungen zusammen reimen.

Gruß,
Stefek

[easyuser]

Hallo Stefek,

da streckt man den kleinen Finger aus...

Also gut. Versionsverwaltung ist nur ein technisches Hilfsmittel zur Projektierung. Im Zusammenhang sicher ein nicht unwichtiger, aber kein entscheidender Faktor.

Wenn man von vorneherein mehrere Module auf einen neuen Stand bringen möchte, so sollte von vorneherein auch das in dieser Art umgesetzt werden. Lieber eine Dimension mehr in Betracht ziehen als später zu viel nacharbeiten.

Am Beginn eines jeden Projekts (egal ob Software oder nicht) steht: "Ist-Zustand" -> "Soll-Zustand".
Alles in Pakete zerlegen, die überschaubar sind, einen definierten Anfang und Ende haben - sicher nicht über Jahre hinweg.
Aber die Theorie ist hier nicht das Thema. Es gibt Bücherregale über Projektmethoden - und mittlerweile sind die Stellenanzeigen überall voll von "Projektmanagern".

Meine Zeit ist auch nicht unbegrenzt. Gerne kann ich mitmachen, aber es soll vorher ein definitives Ziel vereinbart werden. Da ich täglich mit Projektierung zu tun habe, bringt mir persönlich das Lernen von Mini-Projekten nichts.
Wenn es um "Schulung" geht bin ich aber gerne bereit. Auch wenn das Modul am Ende seinen Sinn hat. Bianca hat ja auch einen interessanten Link reingestellt (auch wenn er meines Wissen schon vor ein paar Jahren gepostet wurde).
Dann kann ich ja meine alten Folien wieder rauskramen, die der Vereinsvorstand so genossen hat.

Gruß Michael

[Stefek]

Michael,

ich werd ganz ehrlich zu Dir sein.
Ich glaube nicht, dass es hier viele gibt, die dadran teil nehmen wollen.
Mein Angebot ist nicht ganz uneigennütziger Natur.

Ich komme aus einem SEHR grafisch orientierten Bereich und die ganzen Konsolen ohne Benutzeroberfläche haben schon immer eine Hürde gespielt. (Aber das ist nicht das Thema, auch PHP war für mich zunächst ein Graus, weil ich nichts als aneinandergereihte SYMBOLE gesehen habe - anders als bei HTML, hier konnte man in der Anfangszeit  zumindest mit Editoren arbeiten, die das ganze rendern und einige Hilfstools bereitstellen).

Ich habe einiges Verständnis für Projektierung von Software - Theorie.
Aber keinerlei technische Erfahrung damit (d.h. wie setzt man das auf, dass es läuft und wie handhabt man das).

Mein Angebot ist einfach:

• von mir kommt die meiste Arbeit an der Programmierung.
• Programmiert wird mit Rücksicht auf den Core (aber es werden auch neue Wege gesucht, falls es keine Core-Lösung gibt -> siehe das vernachläßigte Gebiet rund um AJAX).
• Wenn andere das Modul interessant finden, können sie gerne partizipieren (oder im Falle von GitHub das ganze Modul forken)
• die Lizenz soll GNU/GPL sein, wie WB selbst
• das ganze braucht einen technischen Mentor
• Bezahlung gibt es keine - alle Teilnehmenden werden als Mitentwickler genannt
• im Falle von "geforkten" Modulen (die auf der Basis eines anderen Moduls entstehen), werden die Lizenzbestimmungen beachtet - der ursprüngliche DEV nach Möglichkeit kontaktiert.
• Das Produkt für die Community ist ein gut funktionierendes Modul, das sich problemlos in den WB Core integriert (inkl. jQuery, interne Suche)

Mir ist nicht wichtig ein langatmiges Projekt daraus zu machen.

Im Falle des Gästebuch Moduls, das ich komplett umgeschrieben habe, wäre es nicht viel arbeit.

Wir können aber auch ein komplett neues Modul machen. Oder ein Admin-Tool.

Es ist in der ersten Phase wichtig, die Mechanismen des CVS kennen zu lernen, ohne dass man durch die Entwicklung selbst in Verwirrung gerät (was bei einem ZU umfassenden Modul der Fall sein könnte).
So laufen wir nicht Gefahr, zu viel rein zu stecken oder auf der Strecke zu bleiben - mit einem unabgeschloßenen Vorhaben.

Was nicht zu erwarten ist: Fanfaren und Lobgesänge. Die sind nicht zu erwarten, das ist Tradition.
Aber mit ein wenig Glück könnte das ein Anfang neuer Module sein - alte können entweder komplett neu programmiert werden oder auf einen besseren Stand gebracht werden.
Für mich steht fest, sobald ich mich damit vertraut gemacht habe, will ich das auch nutzen und die auf diese Weise entstandenen Module auch verteilen. Programmierung macht Spaß - vielleicht wird sie sogar noch ergiebiger, wenn da mehr Ordnung rein kommt.

Schreib mir gerne auch eine PM.

Gruß,
Stefek

[easyuser]

Eher kurz gehalten. Ausführlich kann es erst werden, wenn mehr Klarheit herrscht, aber das ist eigentlich immer so: Wie die Katze um den heißen Brei, bis man am Ziel ist. Heißt in der Theorie nur anders, aber die ganzen Schnecken-Zyklen sind ja nichts anderes.

Konsolen haben einen unschätzbaren Vorteil. Es hat z.B. seinen Grund, wieso - für viele still und leise - Windows die "Powershell" in Windows 7 zum Standard erklärt hat und in Windows 8 praktisch alles (oder besser: die MMC) auf der PowerShell beruht. Der Windows Server 8 (der bloß ein stinknormales Windows ist, nur andere Komponenten enthält) wird per standard gar nicht mehr eine GUI mitliefert. Linux hat halt doch Einfluss.
Viele andere Modeerscheinungen (JSON) beruhen genau auf dieser Philosophie.
Die Oberfläche ist egal - ob schwarzer Bildschirm ohne Maus oder bunte Oberfläche - alles egal. Kann jeder, wie er will.

Die Mechanismen der Versionierung (CVS lassen wir mal außen vor, das führt nur in die Irre, weil die Technik völlig veraltet ist und kaum noch Anwendung findet) sind völlig unspektakulär.
Man wird enttäuscht sein, wenn es Anwendung findet.
Viel wichtiger ist das Konzept der Programmierung - aber das ist ein anderes, separates Thema. Oder der Programmierungszykl us. ITIL ist heutzutage das Maß dieser aller Dinge. Doch da die Spezifierung durch zig ISO-Nummern in einen anerkannten Standard gehieft ist und in 5 Büchern geschrieben ist braucht man das Thema in einer Forendiskussion gar nicht anschneiden.
Braucht man das bei einem Mini-Projekt? Ja, ich finde schon. Aber das zu erklären - wie gesagt, viel zu umfangreich.

Lobgesänge wird man nie bekommen. Die bekommt das Dev-Team nicht, das Projekt auch nicht und die Modulautoren auch nicht. Das ist eben so - egal wo.
Im übrigen ist Software heutzutage uninteressant geworden. Das ist mittlerweile vorhanden. Wichtig ist die Lösung - Software ist ein Teil davon. Und Lösung bekommt man nur durch Projektierung.

Alles andere dann per PM. Ich erwarte mir von solch einem Projekt übrigens mehr, als du vermuten wirst.

Gruß Michael

[Stefek]

Alles andere dann per PM.
Ich erwarte mir von solch einem Projekt übrigens mehr, als du vermuten wirst.

Na dann bin ich mal gespannt.
Ich melde mich bei Dir.

Gruß,
Stefek

[BlackBird]

Es gibt bereits WB-Module auf GitHub. Nur damit hier nicht der Eindruck entsteht, das sei was ganz Neues.

[Stefek]

Es ist sicherlich nichts neues.
Oben steht ganz gut beschrieben, dass ICH, Stefek, ein Newbie auf dem Gebiet bin, der Nachhilfe sucht.

Stefek