HIVE-Project

Da doch zunehmend Projekte für den Hive gestartet werden und die Frage nach einem SVN Repository immer öfter aufkommt, habe ich mal schnell eins aufgesetzt. Zu erreichen unter:
svn://masterjulian.info:4312 ein webinterface ist unter http://masterjulian.info/websvn/ erreichbar
Ich habe so was noch nie gemacht, aber es läuft. Zum test habe ich einfach mal mein "Arbeitsverzeichniss" hochgeladen. Wer das mit nutzen möchte möge mir einfach seinen gewünschten benutzernamen und paswort per PM zukommen lassen. Im moment ist ohne Anmeldung lesen möglich. Schreiben geht im Moment mit test:test (wie gesagt im Moment alles noch auf Probephase). Wenn das jemand anderes (mit mehr Erfahrung in dem Thema) übernehmen möchte, einfach schreiben, dann schließe ich meins wieder.

Ich hab mal auf Dein WebSVN geschaut. Das ist sehr gut soweit.

@Team: Ich schlage vor, das wir dieses SVN ins Projekt aufnehmen.

Ich muss gestehen, das ich keine Ahnung von so einem SVN Repository habe, würde es aber gern mal versuchen. Hmm, vielleicht kannst du mal eine Minieinweisung machen. Was macht das System genau und wie müsste ich vorgehen, wenn ich dort die Dateien von TriOS einstellen möchte. Wie organisiert man das am besten.

Ich hab das selber auch noch nie gemacht. Bei Wiki gibts nen netten Artikel dazu: http://de.wikipedia.org/wiki/Subversion_(Software)
Einrichten ist einfach. Du erstellst ein Verzeichnis auf deinem Server wo die Daten deines Repositorys rein sollen. Mit "svnadmin create <Verzeichnis>" werden alle nötigen Daten angelegt. Dan passt du im Unterverzeichnis conf die svnserve.conf an (selbsterklärend). Mit "svnserve -d -r /dein/svn/verzeichnis" startest du den Server. Ich habe zusätzlich noch ein Webinterface (in diesem Fall WebSVN) aufgesetzt. Hier musste auch nur die config angepasst werden (wieder selbsterklärend). Da ich z.Z. kein aktives Linux Desktop System habe, kann ich nicht sagen welche GUI's für SVN empfehlenswert sind. Ich nutze unter Windows TortoiseSVN

Der echte Linuxer benutzt für svn eh 'ne Kommandozeile
Wer es doch lieber mit GUI mag: SVN Workbench (für Linux, OS X, Win).
Für Windows empfehle ich aber auch TortoiseSVN.

Und hier gleich noch ein (teilweise übersetztes) Buch zum Thema:

Da Rainers Regime 0.5 in den Startlöchern steht und hier doch schon einiges an Software gebastelt wurde, ist es langsam an der Zeit, mal die Software-Verwaltung anzukurbeln.

Hier ein paar Gedanken zur Strukturierung des svn-Servers:

Getrennte Repositories für TriOS und Anwendungen. Sollten weitere alternative Betriebssysteme entstehen, bekommen die auch ein eigenes Repo. So können gezielt Schreibrechte für verschiedene Entwickler gesetzt werden. So behalten OS-Hacker, die (hoffentlich ) wissen, was sie tun ein wenig die Kontrolle über die notwendige "Basis". Im Anwendungs-Repo kann sich jeder austoben. Eigene Bugfixes/Erweiterungen für ein OS können Nicht-Schreibberechtigte als Patch einreichen und werden dann nach Begutachtung von einem OS-Entwickler ins OS-Repo eingepflegt. Wer brauchbare Patches liefert kann sich die Schreibberechtigung "verdienen". Hat sich so schon oft bewährt und ist mit svn keine Hexerei. Im OS-Repo könnten auch ein paar grundlegende Anwendungen enthalten sein (Editor, StarTracker...), also Sachen die einfach jeder braucht
Getrennte Repos haben außerdem eine eigene Revisions-Nummerierung, sodaß Änderungen an Anwendungen die Revision des/der OS nicht ändern und umgedreht.

Die allseits gebräuchliche Verzeichnis-Struktur branches/tags/trunk. Sehr schön erklärt im SVN-Book (s.o.). Wir hätten dann sowas wie: Ob man für's Software-Repo auch branches/tags/trunk verwendet und wie (global, lokal), weiß ich nicht so recht. Da schwanke ich sehr, hat alles seine Vor- und Nachteile.

Wie sind denn Eure Gedanken dazu?

Volle Zustimmung prinzipiell, das wird wohl das nächste sein was wir uns erarbeiten müssen. Wenn Rainers Regime-Version da ist misten wir die Quellen mal aus und bringen sie in eine richtige Form.

Ich selbst kann noch nichts mit den Begrifflichkeiten (tags, trunks, usw.) anfangen, hab aber die PDF schon auf meiner Todo. Momentan schreib ich halt noch an Teil 2 vom Tut "Build your OS", Teil 3 wird dann eh das TriOS behandeln, weshalb es vorher in "Form" gebracht werden muss. Die kommende Woche hab ich mehr Zeit, da werd ich wohl die PDF mal durchackern.

Ich habe davon auch keine wirkliche Ahnung. Den Server aufsetzen war kein Problem softwaretechnisch aber wie das mit den Verzeichnissen etc... aussieht keine Ahnung. Ich hab mir einfach ein Unterverzeichnis erstellt, indem ich da so herumgereister. Die PDF werde ich mir auch mal anschauen.

Für den Schnelleinstieg und weil diese Teile im SVN-Book noch nicht vollständig übersetzt sind, versuche ich hier mal eine kurze Zusammenfassung der im SVN-Book (Kap.4) vorgeschlagenen branches/tags/trunk-Vorgehensweise (svn-Grundkenntisse setze ich mal voraus):

trunk/ Hier findet die Hauptentwicklung statt. Alle Änderungen und Bugfixes landen hier, manchmal auf einem "Umweg" über den branches-Zweig (s.u.). Der Code im trunk-Zweig ist der aktuelle Stand der "offiziellen" Entwickler-Version und sollte immer prinzipiell lauffähig sein, wird aber möglicherweise noch Bugs enthalten.

branches/ Dieser Zweig wird für zwei Zwecke genutzt: Release-Branches und Feature-Branches.
Wenn wir der Meinung sind, unser Code ist reif für ein Release, legen wir unter branches/ eine Kopie des aktuellen trunk-Zweiges an und geben dieser z.B. den Namen "1.0". Schon haben wir einen Release-Branch. Der hier enthaltene Code wird jetzt ausführlich getestet und erfährt nur noch Bugfixes, keine neuen Features mehr. Parallel kann im trunk-Zweig die Weiterentwicklung für Version 2.0 fortgeführt werden.
Ein Feature-Branch wird verwendet, wenn größere, komplexe Änderungen am Code anstehen, die die Lauffähigkeit und Stabilität des trunk-Zweiges (vorübergehend) beeinträchtigen würden. Man legt in branches/ eine Kopie von trunk/ an, z.b. mit dem Namen "new-netwok-driver". Hier kann jetzt lustig ein komplett neuer Netzwerk-Treiber entwickelt werden, während im trunk-Zweig unbeeinflußt davon weitergewerkelt wird. Ist der Treiber fertig und wird für ausreichend stabil befunden, wird der Feature-Branch in den Hauptentwicklungs- (also trunk-) Zweig reintegriert. Der Feature-Branch kann dann gelöscht werden.

tags/ Wenn der Code in einem Release-Branch (z.B. "1.0") ausreichend getestet und stabil ist, veröffentlichen wir eine neue "offizielle" stabile Version: /branches/1.0/ wird nach /tags/1.0.0/ kopiert. Am Code im tags-Zweig wird nichts mehr geändert. Aus ihm erzeugen wir die Binaries, die dann z.B. auf der Download-Seite als aktuelle stabile Version 1.0.0 bereitgestellt werden.
Werden noch Bugs entdeckt, werden diese im Release-Branch "1.0" gefixt und zu gegebener Zeit als Version 1.0.1 veröffentlicht. Also Kopie vom aktuellen branches/1.0/ nach tags/1.0.1/, hieraus die Binaries erzeugen und als Version 1.0.1 zum Download bereitstellen.

Klingt vielleicht erstmal alles kompliziert, ist es aber nicht wirklich. Der Lernaufwand, den man einmal für Versionsverwaltung aufbringt, zahlt sich bei komplexeren Projekten, vor allem mit mehreren Entwicklern, immer aus. Ich verwende svn sowohl im Job als auch für private Spielereien und möchte ohne schlichtweg nicht mehr programmieren.