Das deutsche Python-Forum

Community Service

Hallo Leute,
Im Rahmen des eben von mir ausgedachten Community Service überlege ich mir, ein öffentliches Mercurial-Repository anzulegen, mit Zugriff für alle, die interesse daran haben. Das sähe dann etwa so aus. Für alle, die nicht wissen was Mercurial ist.. Mercurial ist ein in Python geschriebenes Version Control System (VCS), wie CVS oder Subversion (SVN), am ehesten Vergleichbar mit Canonicals Kind, bazaar-ng.

Einen Überblick über die Funktionen von Mercurial gibt es auf RCSComparisons.

Also, wer interesse hätte so ein Repository zu nutzen, wozu auch immer: wirklich programmieren, testen, damit spielen, der sollte sich melden. Ich würde gerne sehen, ob es überhaupt Sinn macht, sowas einzurichten.

Also wie siehts aus?

Hi

Falls ich es richtig verstanden habe ein Repository in dem man mehrere Projekte anlegen kann und jeder kann bei jedem Projekt änderungen machen?

Wär sicher mal interessant was es alles für Projekte gibt.

Also ich wär dabei.

Gruss

rayo hat geschrieben:Falls ich es richtig verstanden habe ein Repository in dem man mehrere Projekte anlegen kann und jeder kann bei jedem Projekt änderungen machen?

Es sähe etwa so aus: man bekommt ein Repository und in diesem kann man beliebig schalten und walten (naja, keine riesengroßen Dateien, oder verbotene Sachen, aber das ist wohl klar). In diesem Repository kann man nun Projekte anlegen (als Ordner), Dateien reinschaufeln usw.

Das sähe etwa so aus, das ist mein Repository (allerdings ist das ein Subversion-Repository, aber das Prinzip ist das Gleiche). In diesem habe ich zwei Unterordner, "whatsonair" und "snippets" welche ich wie einzelne Projekte verwende. Allerdings, wenn jemand mher als ein Repositoy braucht, sollte da auch kein Problem sein.

Bei dem Projekten kann insofern jeder mitmachen, dass jeder sich eine exakte Kopie des Repositories zieht. Wenn er auf dem Server Schreibzugriff hat, dann kann er seine Änderungen auch wieder auf den Server hochladen, wenn nicht dann kann er auch sein Repository zu einem Server machen. Das ist ein Unterschied zu Subversion.

rayo hat geschrieben:Also ich wär dabei.

Wunderbar!

Ich brauchs nicht ^^ Aber die Idee ist super. Wenn mal trac+hg funktioniert und die kleinen noch existierenden Bugs gefixt sind werd ich wohl das pocoo repository auf hg switchen.

blackbird hat geschrieben:Ich brauchs nicht ^^ Aber die Idee ist super.

Danke
Ich werde die Entwicklung von Mercurial im Auge behalten, da passiert im Moment recht viel.

blackbird hat geschrieben:Wenn mal trac+hg funktioniert und die kleinen noch existierenden Bugs gefixt sind werd ich wohl das pocoo repository auf hg switchen.

Ich weiß nicht, ob ich mein Subversion Repository gegen Mercurial auswechseln würde. Subversion hat ja auch durchaus Vorteile.

Als Idee finde ich sowas nicht schlecht.
Da ich noch nie mit einem Version Control System gearbeitet habe werde ich mir zuerst mal subversion anschauen.

Ob sich so ein "Dienst" wirklich genutzt wird gilt es auszuprobieren.

cu Sebastian

Also generell finde ich die Idee sehr gut... Allerdings würde ich lieber SVN nutzten, weil ich mich darin nun etwas eingearbeitet habe

Außerdem hab ich ja einen kostenlosen SVN/Trac-Server bei python-hosting.com bekommen Allerdings könnten die mal Trac updaten

jens hat geschrieben:Allerdings würde ich lieber SVN nutzten, weil ich mich darin nun etwas eingearbeitet habe

Na, Mercurial ist so schwer auch nicht. Allerdings möglich, dass ich irgendwann auch Subversion anbiete. Im Moment ist es nur Mercurial. Die Administration von Subversion ist einfach ermüdend und ziemlich zeitaufwendig. Dagegen ist Mercurial wenigstens schön schnell und schön einfach.

jens hat geschrieben:Außerdem hab ich ja einen kostenlosen SVN/Trac-Server bei python-hosting.com bekommen

Ich habe auch SVN 1.3.0, allerdings ohne Trac. Ich bin mit ViewCVS+SVN/WebDAV eigentlich zufrieden, brauche kein Trac.

Also ehrlich gesagt, nutzte ich Trac auch nur zum Sourcecode Browsen und da ich dort leider eine ältere Version hab, fehlen noch die Zeilennummern mit html-Anker

Der Vorteil von SVN ist allerdings auch, das man verschiedene GUI-Clients nutzten kann... Ohne GUI ist mir der Kram zu aufwendig

Leonidas hat geschrieben:

jens hat geschrieben:Außerdem hab ich ja einen kostenlosen SVN/Trac-Server bei python-hosting.com bekommen

Ich habe auch SVN 1.3.0, allerdings ohne Trac. Ich bin mit ViewCVS+SVN/WebDAV eigentlich zufrieden, brauche kein Trac.

Ich mag trac. Er ist zwar ein verdammt schlechter Sourcecode browser, aber das wiki, der bug tracker und die plugin schnittstelle machen das Tool echt nützlich.

Und ich verwende nur den Sourcecode browser

Also das Ticketsystem ist vom prinzip auch sehr nett! Aber die Tickets per CMD verwanten, das ist echt mies!

jens hat geschrieben:Und ich verwende nur den Sourcecode browser

Da gibts aber viel bessere mit funktionierendem Highlighting... Websvn, viewcvs sind sehr fein zum browsen und auch sehr schnell.

Also das Ticketsystem ist vom prinzip auch sehr nett! Aber die Tickets per CMD verwanten, das ist echt mies!

Mach ich auch nicht, ich nehm das webfrontend

Das Webfrontend ? Ich hab nur eine Web-Kommendozeile

Leonidas hat geschrieben:

jens hat geschrieben:Allerdings würde ich lieber SVN nutzten, weil ich mich darin nun etwas eingearbeitet habe

Na, Mercurial ist so schwer auch nicht. Allerdings möglich, dass ich irgendwann auch Subversion anbiete.

Hi!

Ich möchte so schnell nicht mehr auf SVN und Trac verzichten. Für SVN gibt es einige praktische Tools wie TortoiseSVN, RapidSVN oder eSVN. Und Trac setze ich jetzt zusätzlich sogar innerhalb meiner Abteilung zum Verwalten der Aufgaben meiner Mitarbeiter und mir ein.

Für jedes größere Projekt gibt es eine eigene Trac-Site in der der Quellcode angezeigt wird. Die Milestones halten mich über den Projektstand auf dem Laufenden. Die Timeline zeigt mir auf was alles so erledigt wurde. Das Wiki wird zur Dokumentation und zur Zusammenarbeit für Textdokumente verwendet. Und das Ticketsystem verwaltet die einzelnen Aufgaben die ich mir und meinen Mitarbeitern zuweise. Zusätzlich kann ich immer zwischen den Tickets und den Repository-Ständen Beziehungen erstellen. Wenn ein Bug ausgebessert wurde, dann gibt es im Ticketsystem einen Link zur SVN-Revision in welcher der Bug ausgebessert wurde.

Seit kurzem wird das Wiki auch als Fehlerdatenbank für den Support eingesetzt. Fehlermeldungen oder andere Symptome werden ins Wiki mit deren Lösungen (und Bildern) eingetragen. Jeder Supportmitarbeiter hat somit eine Wissensdatenbank an der Hand die nicht zu unterschätzen ist, da eine Suche im Trac nicht nur im Wiki, sondern auch in den Tickets und Changesets sucht. Die Suche haben wir so modifiziert, dass von jedem Beitrag bis zu 2000 Zeichen angezeigt werden. Vorher war es einfach zu wenig.

Sorry Leonidas, aber ich verstehe im Moment nicht, warum man nicht eher die Verwendung von SVN und Trac fördern sollte. Trac hat sich schon bei ziemlich vielen Open-Source-Projekten als komfortable Entwicklungs-Platform etabliert.

Wo sind die Vorteile dieses Mercurial gegenüber Subversion? SVN ist bei jeder guten Distribution in wenigen Minuten installiert. Nur bei Debian musste ich umständlich auf Backports zurück greifen, da diese eine nicht mehr unterstütze Uraltversion verwenden. (Falls jemand eine Anleitung für Debian braucht, dann veröffentliche ich diese. Das war nicht so einfach wie ursprünglich gedacht.)

SVN bietet ein eigenes Serverprogramm, das inzwischen sogar ohne den Apachen granulare Berechtigungen überwachen kann. Setzt man den Apachen ein, dann kann mit Webdav gearbeitet werden, was durch den Apachen auch abgesichert (https) werden kann. Inzwischen kann SVN sogar Dateien für die Bearbeitung sperren, was ein vielgewünschtes Feature war.
...

Leonidas, ich finde deine Idee wirklich super, ehrlich. Nur verstehe ich nicht warum, nicht endlich mal eine so gute Programmkombination wie SVN und Trac durch die Community gestärkt und verbessert bzw. ausgebaut wird.

Stattdessen wird immer wieder etwas neues angefangen. Das Ergebnis sind viele Tools, die ziemlich genau das Gleiche tun. Und das Argument, dass SVN einen zentralen Server braucht und einige andere nicht, das ist doch kein Argument für andere VC-Systeme. Wer von uns hat dieses Feature schon mal gebraucht und ehrlich dazu sagen müssen, dass das mit einem zentralen Serversystem nicht machbar gewesen wäre.

So jetzt muss ich wieder Schluss machen. Und hier die Kurze Antwort:
Ich finde die Idee tool, würde aber eine Kombination aus SVN und Trac bevorzugen, da ich diese Kombination für sehr gut und ausbaubar halte.

lg
Gerold

... Sorry für die lange Antwort.

gerold: trac unterstützt hg: http://projects.edgewall.com/trac/wiki/TracMercurial

gerold hat geschrieben:Sorry Leonidas, aber ich verstehe im Moment nicht, warum man nicht eher die Verwendung von SVN und Trac fördern sollte. Trac hat sich schon bei ziemlich vielen Open-Source-Projekten als komfortable Entwicklungs-Platform etabliert.

Gegen trac habe ich ja nichts, es gibt ja auch trac+hg Ist zwar noch nicht ganz fertig, aber das wird schon.

gerold hat geschrieben:Wo sind die Vorteile dieses Mercurial gegenüber Subversion?

• invented here - in Python geschrieben. Das ist nicht nur eine Ego-Sache, das ist auch eine Sache von wegen: wenn etwas nicht geht, habe ich eine Chance das zu reparieren, eingene Plugins zu schrieben, whatever.
• Offline Operationen - manchmal kommt es vor, dass man kein Internetzugriff hat, dann man man mit seinem Repository genauso weiterarbeiten, mit Commits, Branching usw. Wenn man dann wieder zugriff hat, kann man das auch Problemlos wieder mit dem Ursprungsrepository synchronisieren.
• Hat Unterstützung für Plugins. Wenn man mal etwas braucht, was es nicht gibt, kann das schon recht nützlich sein.
• Hat ebenso wie SVN einen Standalone-Server

Klar, man muss nicht alles brauchen und SVN ist teilweise im Moment wirklich viel weiter, was GUIs und auch die Netzwerkfähigkeiten angeht.

gerold hat geschrieben:SVN ist bei jeder guten Distribution in wenigen Minuten installiert. Nur bei Debian musste ich umständlich auf Backports zurück greifen, da diese eine nicht mehr unterstütze Uraltversion verwenden. (Falls jemand eine Anleitung für Debian braucht, dann veröffentliche ich diese. Das war nicht so einfach wie ursprünglich gedacht.)

Backports.org? Eine gute Quelle für Backports.. wobei ich zugebe, dass ich die meisten Backports selber mache(n muss).

gerold hat geschrieben:SVN bietet ein eigenes Serverprogramm, das inzwischen sogar ohne den Apachen granulare Berechtigungen überwachen kann. Setzt man den Apachen ein, dann kann mit Webdav gearbeitet werden, was durch den Apachen auch abgesichert (https) werden kann. Inzwischen kann SVN sogar Dateien für die Bearbeitung sperren, was ein vielgewünschtes Feature war.

Du musst mir die Vorteile von Subversion nicht erklären, ich habe selbst einen WebDAV/DeltaV-Subversion Server, den ich gerne nutze.

gerold hat geschrieben:Leonidas, ich finde deine Idee wirklich super, ehrlich. Nur verstehe ich nicht warum, nicht endlich mal eine so gute Programmkombination wie SVN und Trac durch die Community gestärkt und verbessert bzw. ausgebaut wird.

Auch hier wieder: ich habe gegen Trac nichts gesagt. Nur, dass ich mir im Moment die Administration davon nicht antun will. Außerdem, man kann doch auch Mercurial und SVN nutzen. Das Repositoy hätte ich auch zur Verfügung gestellt, damit man ausprobieren kann, wie sich das "anfühlt". Ich zwinge ja niemanden SVN abzuschwören.

Im Moment siehts so aus, dass es sich für einen User nicht lohnt so ein Respository anzulegen.. aber würden sich denn mehr Luete für Subversion melden? gerold hat schon eines, blackbird auch, ebenso jens. Also für Subversion hätte sich bis jetzt nur Mr_Snede memeldet, das sind auch nicht mehr Interessenten.

Leonidas hat geschrieben:aber würden sich denn mehr Luete für Subversion melden? gerold hat schon eines, blackbird auch, ebenso jens. Also für Subversion hätte sich bis jetzt nur Mr_Snede memeldet, das sind auch nicht mehr Interessenten.

Hi Leonidas!

Für ein SVN mit Trac würde ich mich sehr wohl melden, da ich keinen eigenen privaten Server habe. Und "simplemail" würde ich z.B. gerne in ein SVN-Repository mit Trac legen, dann könnte ich endlich mal ein Setup dafür schreiben, ein paar Beispiele ins Wiki tun und jeder kann ein Ticket erstellen, so dass Fehlermeldungen und Wünsche auch beim Richtigen ankommen.

Auszug aus meinem ToDo-File:
- Statusrückgabe vereinfachen. Die Idee mit dem Statusdict ist nicht
unbedingt ideal. Besser wäre, wenn die Funktion "send" den Status
besser zurück gibt.
- Verbessertes Traceback einbauen, da bei einem Fehler in Zope
keine Meldung über den Fehler ausgegeben wird.
- Setup
- Dokumentation

Also einen weiteren Kandidaten hättest du auch schon dafür. Aber ich will mich nicht schon wieder auf ein neues Code Versioning System einstellen.

lg
Gerold

"simplewinprint" würde ich natürlich auch rein stellen. Aber ich glaube nicht mehr, dass ich da noch viel weiterentwickeln werde. Zumindest hätte es dann ein Zuhause und jeder der möchte könnte daran weiterentwickeln.

lg
Gerold

gerold hat geschrieben:Für ein SVN mit Trac würde ich mich sehr wohl melden, da ich keinen eigenen privaten Server habe.

Hmm, gut zu wissen. Auf dem Python.de-Beta-Server läuft im Moment sogar ein Subversion-Server, aber der ist erstaunlich oft broken. Ich denke, man sollte den nochmal richtig von vorne aufziehen. Allerdings ist das so eine Low-Priority Sache, da der Subversion-Server gerade benötigt wird und da mag ich nicht daran rumdrehen.

gerold hat geschrieben:Also einen weiteren Kandidaten hättest du auch schon dafür. Aber ich will mich nicht schon wieder auf ein neues Code Versioning System einstellen.

Da hätte ich einen Vorschlag für dich: OpenSVN. Die haben dort

• Subversion 1.3.0 (r17949)
• Trac 0.9.2
• Apache 2.0.55

Alternativ auch Python-Hosting.