Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] [gelöst] Git vs hg  (Read 8884 times)

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[DE] [gelöst] Git vs hg
« on: 2011/04/19, 13:21:48 »
Hi,
vielleicht fällt noch jemandem was ein, was ich noch nicht bedacht habe - Ausgangslage:

Externes gemietetes Repo mit der Möglichkeit, svn, git und mercurial zu nutzen. Bisher fahre ich die Kombi rein git + trac für meine  internen Entwicklungen und git-svn + trac für Webseiten.

Ich bin noch mal in mich gegangen, weil zwar svn im Handling durch das Auschecken von Subtrees innerhalb eines Repos gewisse Vorteile für mich brachte. Andererseits  ist der erhöhte Speicherbedarf und die unterirdische Verarbeitungsgeschwindigkeit von Subversion ein echter Blocker.

Bei Git habe ich auf der Negativseite 2 Punkte stehen, die mich stören - keine native Windowsimplementation, ich bin auf msysgit angewiesen, als 2. Punkt die etwas merkwürdige Behandlung von leeren Verzeichnissen, die so nicht unbedingt zu meinen Favoriten gehört.

Aus diesem Grund würde ich als Alternative gerne auf mercurial aufsetzen. Spricht da irgendwas dagegen? Mir ist beim Vergleich der Features nichts aufgefallen, was ich gegenüber Git unbedingt vermissen würde, eigentlich alle Kritikpunkte sind weg, ich frage mich nur, ob ich irgendetwas richtig wesentliches übersehen habe, bevor ich mich an eine Migration machen, die samt Anpassungen in der Programmierung mehrere Tage dauern wird? Gibt es irgendeinen Blocker bei mercurial, den ich übersehen habe?
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline ralul

  • User
  • Posts: 1.814
Git vs hg
« Reply #1 on: 2011/04/19, 22:06:31 »
Da ist gerade eine hervorragende Mercurial hg Schau:
http://www.ibm.com/developerworks/aix/library/au-mercurial/index.html?ca=drs-

Soweit ich verstanden habe gegenüber git:
- besser unter Ms Win
- besseres auschecken von Subtrees

Aber:
- Mehr Festplattenplatz
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #2 on: 2011/04/20, 01:02:20 »
Das mit dem mehr Platz kann ich bestätigen, aber noch nicht quantifizieren. Was bis jetzt aber von mir sehr feststellbar ist - Mercurial ist besser dokumentiert, was beim Stand der Dokumentation von git aber wirklich fast jedem unbeschriebenen Blatt Papier gelingt.  Durch den größeren Hype um Git gibt es aber wesentlich mehr brauchbare Webquellen zum Thema. Dafür sind die Werkzeuge rund um hg in beklagenswertem Zustand, vor allem die fertig paketierten. aptitude search git vs. aptitude search hg.

Mercurial ist aufgrund der etwas geringeren Verbreitung bei Hostern nicht ganz so häufig zu finden wie git. Die Entwicklung rund ums Projekt ist ein wenig "nachlässig". Es scheint so, dass sich die Entwickler selbst genug sind. Es fehlt ein wenig die Ernsthaftigkeit. Das nehme ich übel. Die sind nicht verrückt genug, um vernünftige Arbeit in minimaler Zeit abzuliefern. Beleg dafür: Debian Bug report logs - #577560. und davor und danach. Die Buben haben einfach kein Interesse, wesentliche (für mich) Teile und extensions nach debian zu bringen.  Funktioniert ja auch so. :evil:

Da ist git wesentlich weiter. Ich habe jetzt ein Probem, was durch eine "Nachlässigkeit" wahrscheinlich einige Leute betrifft und davon abhält, hg einzusetzen. Ich habe recht große Subversion-Repositories, die nach hg sollen. Mit hgsvn keine Chance, das rechnet Tage und Wochen. Mein Workaround: Erstellung eines Archivs mit git-svn, konvertierung von git nach mercurial als schnellste und beste Variante. hgsubversion würde helfen, müsste ich aber am Paketmanagement vorbei machen oder "grade mal" zum Paket machen. Auch nicht das große Problem, aber ich hab lieber was Fertiges, gut Funktionierendes.

Ist das Zeug erst mal in Mercurial, ist es geil. Die Unterstützung für den Nicht-Nerd unter Linux und Windows ist wesentlich besser, da ich unter git nur mit dem Tafelgeschirr gearbeitet habe, habe ich alles, was ich brauche. Ich bin nie unter die Prozellan-Ebene gegangen. TortoiseHg mach eine bis jetzt sehr guten Eindruck, sogar bcompare wurde in funktionierend eingebunden. In Linux und Windows. Das macht mich zum Beispiel wieder glücklich. Mit meld als 2. Chance hab ich das noch nicht probiert.

Insgesamt wirkt alles ein wenig aufgeräumter und weniger in die Breite. Durch die Beschränkung auf weniger Funktionen kann ich auch weniger falsch machen. Subtrees auschecken habe ich noch nichts von gelesen, da ist alles besser als git, das kann das nämlich gar nicht. Soll es aber auch nicht. Was hochgradig interessant ist -die Impementation in python. Damit ergeben sich vollkommen neue Möglichkeiten für mich. Ich muss nur noch die Sprache lernen.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #3 on: 2011/04/20, 05:22:40 »
Jetzt habe ich auch ein paar Zahlen vorliegen, so stellt sich mein Testprojekt (lebendes Repo in aktiver Entwicklung dar):

Code: [Select]

gcom-websites - Settings
gcom-websites / svn / 231 MB / Last Commit: 13 Mar 2011 10:04
Alle Webseiteb g-com.eu

gcom-websites-git - Settings
gcom-websites-git / git / 156.8 MB / Last Commit: 13 Mar 2011 10:04
das selbe repo in git

gcom-websites-hg - Settings
gcom-websites-hg / hg / 372.5 MB / Last Commit: 13 Mar 2011 10:04
Meine Seiten in mercurial


Das hat mich dann doch ein wenig überrascht. Zugegebenerweise stört mich das mit dem Platz schon ein wenig, aber da ich in diesem Projekte kaum an die Kritikpunke von Git komme, wird es wohl oder übel Git werden. Andererseits kosten zusätzliche 1G $12 im Jahr bei repositoryhosting. Das sollte für eine aktive closed-Entwicklung auch nicht dass große Problem sein.

Clientseitig mutiert das dann zu:
Code: [Select]

1,4G    ./svn-co/trunk
40K     ./svn-co/.svn
1,4G    ./svn-co

514M    ./git-test/trunk
151M    ./git-test/.git
664M    ./git-test

513M    ./hg-test/trunk
758M    ./hg-test/.hg
1,3G    ./hg-test

516M    ./svn-export/trunk
516M    ./svn-export


Was allerdings grausam war - das Hochladen der Quelldaten in Mercurial dauerte auch wesentlich länger im Vergleich zu Git. Das nächste Kriterium wird die Verarbeitungsgeschwindigkeit, sprich die Trac-Anbindung im Vergleich der Kontrahenten. Etwas positives hat die ganze Geschichte aber doch, mein offenes Zeug kommt nach bitbucket, das macht erst mal einen wirklich guten Eindruck und hat auch in freien Projekten unbegrenzt Plattenplatz. Dann darf auch das Repo gern ein paar Byte größer sein.

Der obligatorische Griff in die braune Masse blieb natürlich nicht aus. Hätte man auch durch Handbuchlesen in Erfahrung bringen können, mercurial unterstützt auch keine leeren Verzeichnisse. Der alte, aber bewährte Griff zu Dummy-Dateien ist also auch hier notwendig. Es bietet sich, als Gemeinsamkeit mit git an, die Datei .gitignore respektiere .hgignore zu missbrauchen, die könnte man wenigstens irgendwann noch mal sinnvoll gebrauchen.


 Mist, eigentlich wollte ich doch nur meine Quellen ordentlich hosten...
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Mr.Smith

  • Guest
[gelöst] Git vs hg
« Reply #4 on: 2011/04/20, 10:57:55 »
Quote
Die Unterstützung für den Nicht-Nerd unter Linux und Windows ist wesentlich besser...

Mal 'ne dumme Frage so ganz nebenbei. Welcher Nicht-Nerd braucht denn Versionsverwaltungen für Quellcode? :roll:
Ganz abgesehen davon, funktioniert git, auch für einen Anfänger wie mich, nicht nur unter Windows unspektakulär einfach!

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #5 on: 2011/04/20, 13:02:23 »
Gegenfrage 1: Wer sprach von Quelltext?
Gegenfrage 2: Schon mal ein Wiki aktiv benutzt? So richtig mit selbst reinschreiben. Da könnte man sehen, dass da Versionen mitgepflegt werden.

So was habe ich mir im gestalterischen Bereich (Layout, Satz, Content - Prospekte, Visitenkarten, Werbung, Webshop etc) immer gewünscht. Ich ändere was und kann schauen, was ich wann geändert habe. Oder z.B. Verträge etc. Das wird im allgemeinen recht gut angenommen. Voraussetzung dafür ist, dass mich das als Benutzer nicht über Gebühr behindert. Du musst mal sehen, wie elektrisch einige Leute werden, wenn die die Möglichkeiten sehen - vorausgesetzt, das geht primitiv einfach.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #6 on: 2011/04/20, 14:59:31 »
Den Sebstversuch, einen Kernel mit hg zu verwalten, ist kläglich gescheitert. 600M git pusteten sich mal ganz rasch auf mehrere G hg auf. Nach 3 Stunden hab ich dann die Übertragung abgebrochen. Da ist git doch irgendwie geeigneter.

Der Rest bleibt auch auf Git. Wie schon angemerkt wurde - Git geht auch unter Windows gar nicht so schlecht. Trotzdem wollte ich eingentlich auf msysgit verzichten. Pech (oder Glück) gehabt. Es geht doch nicht über ausführliche Tests.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline ralul

  • User
  • Posts: 1.814
[gelöst] Git vs hg
« Reply #7 on: 2011/04/20, 18:42:57 »
Klar, git ist eindeutig begrenzt für Kernelentwicklung von Linus Thorwalds konzipiert worden. Und weil es begrenzt ist, können die minimierten Verwaltungsbytes schneller im Internet übertragen werden.

Wenn eine Versionsverwaltung mehr Verwaltungskram speichert, müsste sie auch entsprechend mehr Features können (subtrees), wenn sie nicht einfach nur dumm konzipiert wurde. Aber, dass hg auch keine leeren Verzeichnissse kann, ist ja echt traurig: Für Nicht-Entwicklungszwecke (die Beispiele, die Du oben ansprichst) brauch man einfach leere Verzeichnisse, und es ist Unbedarften der Sinn einer Datei ".gitignore" schwer zu erklären. Bist Du Dir sicher, dass es keine Option bei hg dafür gibt (git kann es definitiv nicht) ?? Svn kann es doch auch ...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #8 on: 2011/04/20, 19:49:29 »
http://hg.intevation.org/mercurial/crew/rev/b98d7ffa5c5b

Da hast Du die Messages. Einiges andere ist möglich mit Klimmzügen. Besonders tragisch empfinde ich nicht die Datenmenge, sondern dass da irgendwie recht wenig Kompression bei der Übertragung passiert. Ob dass an https lag und ob es mit ssh anders wäre, hab ich nicht mehr geprüft. Git ist da irgendwie cleverer aufgebaut. Das mit den leeren Verzeichnissen ist wohl alte Schule, ich erinnere mich daran, dass ich solch einem Mist zusammen mit einem Kollegen einige Zeit in Borland Delphi, C und C++ hinterherdebuggt habe. Hat insgesamt nur 4 voll fakturierte Manntage gedauert ;) Ist halt ein philosophisches Problem. Auch eine leere Menge ist eine Menge mit der Anzahl Elemente 0. Und diese Menge ist existent, abzählbar und somit in der Programmierung zu beachten. Einige Leute sehen das auch so wie ich, baazar soll das können. Das ist aber das geringste Problem. auch SVN hat seine Daseinsbereichtigung, die sich mir zwar nur sehr schwer erschließt, aber was solls.

Um das Problem des partial checkouts zu umgehen kann man natürlich in git auf die subs gehen, dass funktioniert inzwischen ganz gut, in hg tauchen immer wieder die Begriffe nested oder forrest auf. Da die Abhandlung eines partial checkouts aber nicht ganz trivial ist, wird es wohl auf reines ziehen ohne die Möglichkeit zu commiten hinauslaufen. Datenaustausch via patch ist ja auch was Feines. Inzwischen bin ich in der Theorie auch soweit, dass ich einen klassischen Export hinbekomme, mit den selben Einschränkungen bezüglich der Commits - auf Deutsch Dummsinn.

Torwalds hat das übrigens nicht nur für die Kernelentwicklung geschrieben, sondern als eine Art generelles versionierendes Dateisystem. Der Typ ist irgendwo einfach nur genial. Das Problem mit den Verzeichnissen ist seit Jahren bekannt, es findet sich nur keiner, der das implementiert. Hab ich gestern noch in einer Diskussion zum Thema gelesen, Issuenummer hab ich mir natürlich nicht gemerkt.

Sei es wie es ist, trotzdem finde ich mercurial im lokalen Netz gar nicht schlecht. Auf jeden Fall haben die Buben bei Bitbucket da eine schicke Oberfläche rumgebaut, die was hermacht. Wenn das wirklich Jira ist, lerne ich eventuell irgendwann mal, wie man einen Tomcat-Server aufsetzt. Bis dahin wird es wohl Redmine (Chiliproject) werden, dass ich von Tag zu Tag besser finde. Das werde ich aber garantiert nicht übers Knie brechen, Trac ist ja, vernünftig eingerichtet, auch recht mächtig. Und ich hab den großen Vorteil, dass ich von dieser ganzen Thematik keinen blassen Schimmer habe, also da vollkommen unvoreingenommen rangehen kann. Python oder ruby höhren sich auf jeden Fall erotischer an als Java.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

DonKult

  • Guest
[gelöst] Git vs hg
« Reply #9 on: 2011/04/20, 22:36:51 »
Meines wissens nutzt Mozilla Corp. mercurial.

Die Ansicht das ein leeres Verzeichnis etwas ist teile ich übrigens nicht. Für mich ist auch ein Verzeichnis nichts. Um mathematisch zu bleiben: Wie ein Punkt - zwar gut zu beschreiben, aber effektiv nicht vorhanden da keine Ausdehnung. Verzeichnisse bilden eine Gruppierung für Dateien die den Inhalt tragen von denen es unterschiedliche Versionen gibt. Welchen Inhalt tragen den Verzeichnisse…?
(Zitate des Tages: "Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist." ~ Stanislaw Jerzy Lec)

bzr hast du selbst schon erwähnt, sonst hätte ich mich gewundert, dass das nicht vorkommt.

An deinen Größentests kann irgendwas nicht stimmen. Es widerspricht dem Sinne des dezentralen VCS es in Server und Client zu unterscheiden -- vor allem wenn man dabei signifikante Größenunterschiede beobachten will - immerhin ist jeder Checkout vollständig…

Was hg forest betrifft so ist das meineswissens "nur" eine simple Verwaltung von unterschiedlichen Bäumen (=Projekten) innerhalb eines Überverzeichnisses als wald/baumA wald/baumB wald/baumC und du kannst in wald deine pulls durchführen und die Bäume werden dann gepulled. Sowas sollte es auch für git geben…

bitbucket für git heißt übrigens github und ist wohl das ältere von beiden…

Und trac bietet auch hg-Plugins an…

bezüglich: #577560 - ich verstehe deinen Zorn nicht. Es hat sich bisher keiner gefunden, der das paketieren möchte. So what? Du möchest es ja scheinbar auch nicht tun, obwohl du es ja scheinbar brauchen kannst was ja jetzt nicht gerade bei vielen der Fall ist…
(das Problem an den Konvertern ist ja auch: Man braucht das einmal - und dann?)

Mr.Smith

  • Guest
[gelöst] Git vs hg
« Reply #10 on: 2011/04/20, 22:54:01 »
Quote
Um mathematisch zu bleiben: Wie ein Punkt - zwar gut zu beschreiben, aber effektiv nicht vorhanden da keine Ausdehnung.

Wenn ein Punkt effektiv nicht vorhanden wäre weil er "keine Ausdehnung" hat würde man ihn dann als Punkt wahrnehmen?
Selbst schwarze Löcher sind vorhanden, obwohl man sie nicht wahrnehmen kann, nur ihre Auswirkungen.

Offline gerd

  • User
  • Posts: 147
[gelöst] Git vs hg
« Reply #11 on: 2011/04/20, 23:27:51 »
Oh je. Ein mathematischer Punkt (der in der Tat nicht wahrnehmbar ist) ist ein recht schlechter Vergleich zu leeren Ordnern. Aber egal.
Leere Ordnern können dazu dienen:
- beim Aufbau eine Struktur zu geben bzw. einen Rahmen für zukünftige Änderungen zu geben
- Informationen über den Ordnernamen (durchaus üblich) zu übertragen

Ein schwarzes Loch ist übrigens kein Punkt, sondern -  so existent - etwas Kugelartiges

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #12 on: 2011/04/21, 01:17:11 »
@gerd: man könnte sagen, schwarze Löcher haben etwas sehr anziehendes.

Als  Strukturierungspunkt: Wenn das Verzeichnis für die Strukturierung so wichtig ist, dann sollte es auch eine README enthalten. Dann it es nicht mehr leer. Sonstige benötigte Verzeichnisse hat die Programmierung bei Bedarf anzulegen, die müssen nicht unbedingt im Repository enthalten sein. Stil und Ansichtssachen. Für definitive Strukturmittel wie die Ablage temporärer Dateien biten sich wirklich die .xyzignore-Dateien an.

@donkult: Zwiespältig. Siehe 0 und null.

Zur Paketierung: Es ist übrigens nicht so, dass nicht schon mal der Versuch unternommen worden wäre mit den Paketen. Dem von mir angeführten Fehler ging ja etwas voran. Es gab durchaus Bestrebungen, debian-Pakete bereitzustellen.
https://bitbucket.org/yuja/hgsubversion-deb/overview
Ich werde das garantiert nich an- und packen. Warum sollte ich ein Paket packen, was ich wahrscheinlich nie benutzen werde? Der Zustand der Programmierung ist halt noch nicht so, dass es problemlos möglich wäre. Wäre der Rest von mercurial brauchbarer, könnte man sich das ans Bein binden. Ist es aber nicht. So ist es nur ein weiterer negativer Punkt im direkten Vergleich. Git ist einfach erwachsener.

Nach den Tests von gestern werde ich meine umfangreicheren Pakete weiter mit git verwalten. Für kleinere Sachen werde ich mir in aller Ruhe mal bitbucket und vor allem
JIRA zu Gemüte führen. Eine Kombi von Jira und Git sehe ich auch sehr positiv - wenn ich je in die Verlegenheit komme, so was zu brauchen, habe ich dann einen fundierten Ansatz.

github und bitbucket kann man imho so miteinander nicht vergleichen. Meine Ansicht. Da ich github für meinen aptosid-Kernel nutze, weiss ich eigentlich recht genau, was mir daran auf den Sack geht. Es ist eigentlich wie immer: eine Kombination von beiden Sachen wäre für mich das Optimum. Was ich an jira und trac so toll finde, kommt bei vielen anderen nicht so gut an. Die exzellenten Trackingmöglichkeiten, eingebettet in eine tolle Oberfläche.

Was die Größenunterschiede betrifft, kannst Du mir ruhig glauben. Ich sehe da auch keine signifikanten Unterschiede in meinen Zahlen, die sich nicht erklären lassen. Einer der Hauptkritikpunkte an hg ist doch die doppelte Ablage der Objekte. Warum das so sein muss, hab ich nicht verstanden, suche ich aber gern noch mal raus.
Auf jeden Fall sollten man unterscheiden - die Unterscheidung ist bei git die eines vollstädigen Clones gegenüber --bare. Die selbe Sache in unterschiedlicher Verpackung. Das liegt aber auch in der Natur der Sache.

Das, was Du als so simpel ansiehst, ist es nicht: subrepos haben bei git ewig nicht wirklich funktioniert, die nested Sachen habe ich mir nicht genauer angesehen. nested REpositories ist nicht einfach das Zusammenprömpeln von Verzeichnissen, sonst wäre es ja noch erstaunlicher, dass es da überhaupt Probleme geben sollte.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

hefee

  • Guest
[gelöst] Git vs hg
« Reply #13 on: 2011/04/21, 01:56:56 »
ich selber habe jetzt hgsubversion nicht probiert, aber vllt. ist es mit einem einfach hg clone auch einfach getan, weswegen auch niemmensch findet das zu paketieren was so einfach kurz istalleirt werden kann ;) Natürlich ist ein deb schöner;)

Aber nachdem ich jetzt monatelang an einem Rechner arbeiten musste, bei dem ich keine Admin rechte hatte habe ich zu schätzen gelernt als benutzer solche Sachen im home-dir platzieren zu können.

trac/mecurial rennt bei mir schon seit zwei Jahren ohne Fehler durch...

achso vllt. noch zwei screencasts(englisch) der pycon2010, ein bischen geschichte zu git/hg und unterschiede & gemeinsamkeiten:
"Modern version control: Mercurial internals (#113)": http://us.pycon.org/2010/conference/schedule/event/132/
"Hg and Git : Can't we all just get along? (#154)": http://us.pycon.org/2010/conference/schedule/event/137/

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] Git vs hg
« Reply #14 on: 2011/04/21, 08:31:41 »
Quote from: "hefee"
ich selber habe jetzt hgsubversion nicht probiert, aber vllt. ist es mit einem einfach hg clone auch einfach getan, weswegen auch niemmensch findet das zu paketieren was so einfach kurz istalleirt werden kann ;) Natürlich ist ein deb schöner;)

hgsubversion wäre die Voraussetzung für hg clone ...
Der kürzeste Weg zwischen 2 Punkten ist der Umweg:

in /etc/mercurial/hgrc.d/hgext.rc
Code: [Select]

# Extensions included in Mercurial listed in alphabetical order
#[extensions]
#hgext.git =
-->
# Extensions included in Mercurial listed in alphabetical order
[extensions]
hgext.git =

Damit ist interoperabilität mit git hergestellt. Da müsste meiner Meinung nach jetzt ein hgsubversion rein.

Code: [Select]

git svn clone https://server.de/meinrepo/svn/verzeichnis mein-checkout-git
hg clone mein-checkout-git mein-checkout-hg
nano mein-checkoupt-hg/.hg/hgrc

Hier dann noch auf den hg-server umbiegen und pushen. Ich habe ab sofort ein hg-Repository mit kompletter Historie. Leider ist das eine Einbahnstraße.

hgsubversion könnte dieses Manko lösen, wenn es denn stabil wäre. Ich habe jetzt eine Zeit lang mit git-svn gearbeitet, da war gegenüber reinem svn schon ein Fortschritt, wie man aber im obrigen Block sieht, müsste man eigentlich mit dem Klammerbeutel gepuert worden sein, wenn man nicht komplett auf hg umstellen möchte. Die Idee eines zentralen svn mit vorgeschaltetem git-svn wurde ja auch bei KDE längere Zeit erfolgreich praktiziert.

Bei meinen kleineren Sachen ist svn jetzt erfolgreich gestorben und durch hg ersetzt worden. git hätte es auch getan, aber irgendwie gefällt mir mercurial.

Der Kernel liegt weiterhin bei github und wird da auch bleiben. Die Seiten stelle ich von svn/git-svn auf reines git um, es muss zwar ein wenig umstrukturiert werden, aber was solls. Im Großen und Ganzen war die ganze Sache ein voller Erfolg. Jetzt muss nur noch Chili oder Trac an den Start kommen, wobei mir Trac zwar gut gefällt, so rein vom Gefühl aber Chili eventuell den etwas weiteren und auf Dauer besseren Umfang hat. Da ist die Entscheidung ganz einfach - Ich setze beides auf und wir nutzen dann einfach nach ausführlichen Tests das, was besser gefällt und womit alle besser klar kommen. Je nach Lust und Laune ist auch Jira + Wiki noch nicht aus dem Rennen, was da stört ist im Moment nur Tomcat.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen