Das deutsche Python-Forum

Hallo,

mich würde einfach mal interessieren, wie ihr an eine neue Programmidee / ein neues Programmprojekt herangeht. Ich selbst habe vor einigen Wochen mit einem Kalenderprogramm begonnen und merke mehr und mehr, dass ich mir einiges an Arbeit hätte sparen können, wenn ich mir im Vorfeld bereits mehr Gedanken über benötigte Funktionen, Klassen, Datenstruktur und nicht zuletzt auch das GUI gemacht hätte.
Ich tue mir allerdings etwas schwer damit, meine Ideen in eine dann "codeübertragbare" Form zu bringen. Als Hilfsmittel verwende ich in erster Linie Collegeblock und Bleistift und übertrage das dann in xMind, damit ich auch nach Tagen noch verstehe, um was es mir ging...
Trotz meiner Notizen und xMind muss ich immer wieder umprogrammieren, neue Klassen erstellen oder bestehende Klassen zusammenführen bzw. ganz löschen. Wie das Programm strukturiert bzw. bereits bestehende Klassen aufgebaut sein müssen merke ich erst, wenn ich damit beginne, neue Programmfunktionen zu schreiben.

Meine Fragen also an Euch:
Wie geht ihr vor?
Welche Hilfsmittel verwendet ihr?
Sind Struktur und Klassenaufbau anfangs schon klar oder entwickelt sich das bei Euch auch erst während der Arbeit?

Hmm... Bin schon sehr gespannt, welche Arbeitsweisen ihr so verwendet...

Liebe Grüße
mutetella

Block und Bleistift sind schon mal ein excellenter Anfang, mach ich auch so. Danach kommen erste grobe digitale Skizzen und Diagramme, um die Zusammenhänge zu erkennen. Dann kommt zeitgleich erte Programmieransätze und der Feinentwurf. Dafür versuche ich mich zur Zeit in der Anwendung von Tests, hab da aber noch so meine Schwierigkeiten.
Wichtig ist, wie ich finde, den Feinentwurf nicht nur auf dem Papier zu machen, sondern sobald man die Funktionalität definiert hat und eine grobe Struktur erstellt ist, diese auch umzusetzen.

Gruß Uwe

Hängt extrem vom Projekt ab. Es gibt Dinge da kann ich mit gutem Gewissen 'einfach drauf los hacken'. In anderen Fällen setze ich mich erst einmal hin (oder geh Spazieren ) und mach mir Gedanken über die grobe Architektur. Ich versuche dabei mehr über Dienstleistungen nach zu denken als über Klassen oder Funktionen. Und dann je nach Komponente geht der Prozess wieder von vorne los und diese wird verfeinert. In vielen Fällen (gerade wenn es sich um Neuland handelt) macht es mMn auch Sinn einfach einmal einen, vielleicht sogar 2-3 Prototypen zu bauen. Viele Probleme lassen sich nur sehr schwer voraussehen werden jedoch schon beim ersten Prototypen offensichtlich.

Zu den Hilfsmitteln, wenn ich das ganze nur für mich selber mache reichen mir Oft einfache Textdateien. Wenn das ganze anderen Entwicklern präsentiert werden soll ich oft UML das Werkzeug der Wahl.

Ich modelliere jedoch meistens nicht bis ins letzte Detail. Da ist mir oft die Gefahr zu gross mich zu verrennen.

veers hat geschrieben:Hängt extrem vom Projekt ab. Es gibt Dinge da kann ich mit gutem Gewissen 'einfach drauf los hacken'. In anderen Fällen setze ich mich erst einmal hin (oder geh Spazieren ) und mach mir Gedanken über die grobe Architektur. Ich versuche dabei mehr über Dienstleistungen nach zu denken als über Klassen oder Funktionen.

Dienstleistungen ist für mich das Stichwort. Ich verwende seit einiger Zeit OPDs (Object-Process-Diagramm) um mir Zusammenhänge klarzumachen. Diese Notation gefällt mir sehr gut, weil ich mich damit nicht an Klassen etc. fessele sondern der Fokus tatsächlich auf den Prozessen liegt. Ob ich den Prozeß dann später als Methode oder Funktion umsetze, bleibt dabei offen. Einfach mal nach "Object Process Methodology" googeln. Nachteil: Es gibt keine freie Software, die einem dabei hilft. Und die kommerzielle ist mit rund 3000 EUR definitiv zu teuer für Hobby-Programmierer. Aber allein die Notation ist schon sehr hilfreich.

Ein wichtiges Augenmerk liegt bei mir immer darauf, die einzelnen Komponenten möglichst unabhängig voneinander und damit testbar zu halten (unittests, dependency injection). Dazu sollten Erzeugung und Funktion stets voneinander getrennt werden.

Vorgehen: Erst einmal das System "erkunden", sprich die Anforderungen und Zusammenhänge so gut wie möglich aufs Papier bringen. Dabei versuchen, Gemeinsamkeiten und Unterschiede zwischen Bereichen zu identifizieren. Problemstellen ausfindig machen. Es gibt eigentlich in jedem Projekt irgendeinen Bereich, für den mir die notwendige Technologie bzw. das entsprechende Wissen fehlt. Hier muß recherchiert werden. Kleine Prototypen für Teilbereiche sind auch sehr hilfreich. Wenn du das Gefühl hast, genügend Überblick zu haben, einfach anfangen. Ich arbeite gerne Top-Down, weil man dann schnell etwas in der Hand hat, was irgendwie läuft. Das ist für meine Motivation sehr wichtig. Trotzdem wirst du immer wieder in die Situation kommen, große Teile deines Codes wegschmeissen und neu schreiben zu müssen. Für eine Planung, die auch wirklich hinhaut braucht es ab einer gewissen Größenordnung viel viel Erfahrung. Versuche in erster Linie, funktionierenden Code zu schreiben, und ihn erst dann zu optimieren bzw. "schöner" zu machen, wenn er läuft. Mein Fehler ist, daß ich immer viel zu lange nach der elegantesten Lösung suche.

Edit: Oh man, der Kaffee will heute mal wieder nicht wirken ...

Hallo mutetella!

Ich verwende FreeMind um die Anwendung zu planen. Später, im Laufe der Entwicklung, wenn ich komplexere Probleme zu lösen habe, dann nehme ich auch FreeMind um damit Knoten in meinem Hirn zu lösen. Das funktioniert für mich überaus gut.

Dann plane ich die Ordnerstruktur (Pakete, Module) und mache mir Gedanken darüber, welche Probleme ich in welchem Paket/Modul lösen werde. Diese Ordnerstruktur vergleiche ich dann wieder mit der Mindmap, bis alles zusammenpasst -- also alle gestellten Aufgaben in der Ordnerstruktur abgebildet werden können.
So plane ich den Aufbau der Anwendung -- Datenzugriff, GUIs, Resourcen, Libraries, usw.

Nachdem ich die grobe Ordnerstruktur habe, pflege ich sie in ein Subversion Repository ein und erstelle ein Trac Projekt.
Dann plane ich in Trac die Milestones und lege mir Tickets für die einzelnen Programmteile und Aufgaben an. Am Anfang erst mal grob und später immer detaillierter. Das hat den Vorteil, dass ich im Laufe der Entwicklung am Morgen eines Tages, wenn ich noch nicht ganz fit bin, nicht immer nachdenken muss, mit was ich an diesem Tag beginne. Ich schau' ins Trac und kann los legen.

Während der Entwicklung des Programmes mache ich mir vermehrt Notizen zu den Aufgaben im Trac. Immer wenn mir (nebenbei) mal einfällt, wie ich dies oder jenes Problem lösen könnte, schreibe ich es ins Trac zur jeweiligen Aufgabe dazu. Wenn es dann so weit ist, dass ich das Ticket abarbeite, dann habe ich meist schon alle Informationen dazu im Ticket stehen.

mfg
Gerold

veers hat geschrieben:Hängt extrem vom Projekt ab. Es gibt Dinge da kann ich mit gutem Gewissen 'einfach drauf los hacken'. In anderen Fällen setze ich mich erst einmal hin (oder geh Spazieren ) und mach mir Gedanken über die grobe Architektur. Ich versuche dabei mehr über Dienstleistungen nach zu denken als über Klassen oder Funktionen. Und dann je nach Komponente geht der Prozess wieder von vorne los und diese wird verfeinert. In vielen Fällen (gerade wenn es sich um Neuland handelt) macht es mMn auch Sinn einfach einmal einen, vielleicht sogar 2-3 Prototypen zu bauen. Viele Probleme lassen sich nur sehr schwer voraussehen werden jedoch schon beim ersten Prototypen offensichtlich.

Ja, so ähnlich mache ich es auch. Ich kann am Computer nicht über die Sachen denken, brauche da etwas Abstand. Im Idle-Modus fallen mir so Sachen leichter. Wenns um algorithmische Sachen geht, macht es für mich auch Sinn mir Beispieldaten auszudenken und mit diesen auf dem Papier zu spielen bis mir irgendein Vorgehen ausreichend gefällt um implementiert zu werden. Generell gehe ich oft nach dem Vorgehen "the simplest thing that could possibly work" vor auch wenn das bedeutet dass ich manchmal Teile neuschreiben muss. Aber dann weiß ich wenigstens was die wirklichen Anforderungen sind und muss nicht mit irgendwelchen Phantomanforderungen rechnen die irgendwann vielleicht, vielleicht nicht dazu kommen aber dafür den Code komplex machen.

Achja und ich habe eine starke Abneigung gegen Notation. Mindmapping hilft mir null, außer dass ich damit Zeit vertrödle und hübsche Bilder male, die nicht so richtig erklären wie ich ein Projekt eigentlich angehen will. Jedem das seine.

@Käptn Haddock:

Dafür versuche ich mich zur Zeit in der Anwendung von Tests, hab da aber noch so meine Schwierigkeiten.

Was meinst Du mit "Anwendung von Tests"?

@veers:

Ich versuche dabei mehr über Dienstleistungen nach zu denken als über Klassen oder Funktionen.

Meinst Du mit Dienstleistungen die Funktionalität des Programmes? Denn genau da liegt oft mein Problem, dass ich wohl eine ziemlich genaue Vorstellung dessen habe, was das Programm leisten soll, allerdings noch keinen verwertbaren Überblick darüber, welchen Einfluß Funktion A auf Funktion B einmal haben wird oder einmal haben muss. Konkret: Ich hatte in meinem Kalenderprogramm eine Klasse Coords() und eine Klasse View(). Coords() war dafür zuständig, die Koordinaten für die Tage und die Termine einer Kalenderansicht zu berechnen und bei Bedarf (z. B. ein Klick auf einen Termin) wieder auszuspucken. View() wiederum erhielt von Coords() die Koordinaten und zeichnete die Kalenderansicht. Irgendwann legte ich beide Klassen zusammen, da das ermitteln der Koordinaten und das Zeichnen der Ansicht so nah beieinander liegen, dass es mir unsinnig erschien, diese so eng miteinander verwobenen Funktionen in verschiedene Klassen zu deponieren. Inzwischen habe ich also dafür nur noch die Klasse View(). Diese Klasse wiederum muss momentan wieder "umgebaut" werden, da ich sie nicht nur für die Kalenderansicht, sondern auch für den Kalenderpicker verwenden möchte, da der wxPython-eigene datepicker nicht so dolle ist.
Und so weiter, und so weiter... Denkst Du nicht, dass eine gründlichere Planung der Programmstruktur wichtiger ist, als über die Dienstleistungen nachzudenken, die sich doch in einen gut aufgebauten Code viel einfacher einbauen lassen, als schlecht durchdachten Code ständig umwerfen zu müssen?
Oder reden wir von zwei unterschiedlichen Dingen?

@Pekh:

Einfach mal nach "Object Process Methodology" googeln.

Werde ich machen, danke für den Tipp, klingt interessant.

Mein Fehler ist, daß ich immer viel zu lange nach der elegantesten Lösung suche.

Ich weigere mich, darüber nachzudenken, wieviele Stunden ich damit schon verbummelt habe...

@gerold:

...dann nehme ich auch FreeMind um damit Knoten in meinem Hirn zu lösen.

Wie oft schon hab' ich in meinen VIM gestarrt und hatte das Gefühl, mir explodiert gleich der Kopf, weil ich Zusammenhänge nicht mehr übereinander gebracht habe. Ohne xMind wäre ich schon längst gescheitert...
So wie Du Deine Vorgehensweise beschreibst stelle ich mir das auch in etwa vor, das von Dir erwähnte Trac Project habe ich mir installiert, werde ich mir die Tage mal zu Gemüte führen. Ich muss zu meiner Schande gestehen, dass ich mich mit Versions-Systemen noch überhaupt nicht auseinandergesetzt habe. Irgendwie ist mir das Thema zu groß... Aber selbst für einen Hobbyprogrammierer kann das wohl sehr hilfreich sein.

Das hat den Vorteil, dass ich im Laufe der Entwicklung am Morgen eines Tages, wenn ich noch nicht ganz fit bin, nicht immer nachdenken muss, mit was ich an diesem Tag beginne.

Wenigstens dafür sind meine kläglichen Notizen nütze: Zu wissen, wo es weitergeht!

@Leonidas:

Generell gehe ich oft nach dem Vorgehen "the simplest thing that could possibly work" vor auch wenn das bedeutet dass ich manchmal Teile neuschreiben muss. Aber dann weiß ich wenigstens was die wirklichen Anforderungen sind und muss nicht mit irgendwelchen Phantomanforderungen rechnen die irgendwann vielleicht, vielleicht nicht dazu kommen aber dafür den Code komplex machen.

Nun ja, zwischen schwarz und weiß liegen die vielen Grautöne... Ich geb' Dir natürlich Recht und stehe auch oft in der Gefahr, über Eventualitäten nachzudenken, die noch gar nicht eingetreten sind. Andererseits denke ich, dass es schon auch Sinn machen kann, das eine oder andere "Leerrohr" einzuziehen. Klar, natürlich nur, wenn man davon ausgehen kann, dass man später auch Kabel reinlegt.


Jedenfalls schon mal "Danke!" an Euch alle. Bin gespannt, ob noch mehr kommt...

Liebe Grüße
mutetella

@mutetella: Dein Einwand Programmstruktur vs. Dienstleistungen verstehe ich nicht so ganz. Man kann doch keine Programmstruktur unabhängig von dem was das Programm leisten soll entwerfen, denn die Struktur muss sich doch an dem orientieren was das Programm leisten soll. Das ist doch letztendlich das Ziel, die Dienste zu erbringen, und die Programmstruktur ist nur das Mittel dazu.

Ich meine ja auch nicht, dass man sich keine Gedanken über die Features eines Programmes machen muss. Geht ja überhaupt nicht. Natürlich ist das Ziel eines jeden Programmes, irgend einen Dienst zu verrichten. Ich hatte veers allerdings so verstanden, dass er sich im Vorfeld eher bzw. mehr Gedanken über die Features als über die Struktur eines Programmes macht. Ich wiederum finde, dass es doch vielleicht zweckmäßiger ist (nachdem die Grundfeatures des Programmes bekannt sind), sich um eine ordentliche Struktur zu kümmern. Wenn dann während der Entwicklung das eine oder andere Feature dazukommen soll, ist die Implementierung in guten Code einfacher als sich dann jedesmal damit herumschlagen zu müssen, zu entflechten, umzuräumen oder komplett neu zu strukturieren.
Nicht ganz so extrem, aber im Ansatz habe ich gerade damit meine Probleme. Beginne ich, eine neue Funktion in meinen Kalender einzubauen muss ich öfters Klassen oder sogar Strukturen ändern. Und ich werde den Verdacht nicht los, dass ich mir mit einer anderen/besseren Programmplanung das eine oder andere davon sparen könnte.

Gruß
mutetella

Hab jetzt nicht alle Beiträge vor mir ausführlich gelesen. Also verzeih mir, wenn ich etwas wiederhole.
Du kannst das Programm DIA nutzen um UML Diagramme komfortable zu erstellen.
Ich persönlich bevorzuge allerdings Bleistift, Kugelschreiber und meinen karierten Block.

mutetella hat geschrieben:Ich muss zu meiner Schande gestehen, dass ich mich mit Versions-Systemen noch überhaupt nicht auseinandergesetzt habe. Irgendwie ist mir das Thema zu groß... Aber selbst für einen Hobbyprogrammierer kann das wohl sehr hilfreich sein.

Ich kann dir versichern, dass es sich lohnt sich mit einem DRCS wie z.B. Git oder Mercurial auseinanderzusetzen.

mutetella hat geschrieben:Ich muss zu meiner Schande gestehen, dass ich mich mit Versions-Systemen noch überhaupt nicht auseinandergesetzt habe. Irgendwie ist mir das Thema zu groß... Aber selbst für einen Hobbyprogrammierer kann das wohl sehr hilfreich sein.

http://chaosradio.ccc.de/cre130.html

mutetella hat geschrieben:Ich muss zu meiner Schande gestehen, dass ich mich mit Versions-Systemen noch überhaupt nicht auseinandergesetzt habe. Irgendwie ist mir das Thema zu groß... Aber selbst für einen Hobbyprogrammierer kann das wohl sehr hilfreich sein.

Es ist nicht hilfreich, es ist absolut notwendig, dass wirst du aber erst dann wirklich merken wenn du es brauchst und nicht benutzt Schau dir mal hginit an, dass erklärt ziemlich gut wie Mercurial funktioniert, wie man es benutzt aber vorallem dass Konzept DVCS überhaupt.

@DasIch:
Danke für den Link, hab' das jetzt nur mal überflogen, find' ich sehr interessant. Könntest Du mir vielleicht sagen, was denn der Unterschied zwischen HgInit und Subversion ist, falls es überhaupt einen gibt. Man stößt halt dauernd auf Subversion, für alles mögliche gibt es Subversions-Plugins und -Unterstützung. Ist das grundsätzlich mit HgInit auch gegeben? Oder ist die Frage jetzt doof und erledigt sich, wenn ich mich noch tiefer reinlese...?

@fana:
Wow, danke... Wenn ich da durch bin, kann ich Euch allen hier was erzählen...

@derdon:
Jepp, den Eindruck hab' ich inzwischen auch. Dachte, so als Hobbyprogrammierer ist das alles a bisl übertrieben. Aber mein Kalenderprogramm wird Woche für Woche umfangreicher. Dem ist es egal, ob ich aus Hobby oder sonstwas programmier... Ohne Hilfsmittel ist das einfach nicht zu schaffen. Jedenfalls nicht mit meinem Hirn!

@Pascal:
Ja, mit DIA hab' ich vor längerem auch schon versucht klarzukommen. Hab's aber dann gelassen, weil ich DIA nicht so dolle find' und weil für mich UML-Diagramme nicht nötig sind und mir auch nicht weiterhelfen. Aber auf dem Weg über DIA bin ich dann irgendwie bei xMind gelandet. Zum schnellen "Ordnung ins gedankliche Klassen-Chaos schaffen" ist das in meinen Augen supergenial. Und ja: Bleistift und Block kann bisher noch kein Tool ersetzen...


Vielen Dank für Eure großartige Hilfe!!!

Gruß
mutetella

mutetella hat geschrieben:Danke für den Link, hab' das jetzt nur mal überflogen, find' ich sehr interessant. Könntest Du mir vielleicht sagen, was denn der Unterschied zwischen HgInit und Subversion ist, falls es überhaupt einen gibt. Man stößt halt dauernd auf Subversion, für alles mögliche gibt es Subversions-Plugins und -Unterstützung. Ist das grundsätzlich mit HgInit auch gegeben? Oder ist die Frage jetzt doof und erledigt sich, wenn ich mich noch tiefer reinlese...?

HgInit ist nur der Name des Tutorials, das DVCS heisst Mercurial bzw. hg. Der Unterschied zu einem VCS ist dass es verteilt ist. Dass heisst bei Subversion hast du einen Server auf dem dass Repo liegt und alle Entwickler arbeiten auf diesem Server, was mehr Aufwand zufolge und hat und du musst ständig online sein um alle Funktionen nutzen zu können. Außerdem haben VCS wie Subversion, CVS etc. noch einige andere Nachteile mit denen du dich gar nicht erst beschäftigen willst.

DasIch hat geschrieben:was mehr Aufwand zufolge und hat und du musst ständig online sein um alle Funktionen nutzen zu können. Außerdem haben VCS wie Subversion, CVS etc. noch einige andere Nachteile mit denen du dich gar nicht erst beschäftigen willst.

Hallo!

Ja, Subversion hat ein zentrales Repository, welches du zum Ein- und Auschecken der Daten brauchst. Aber niemand schreibt dir vor, dieses Repository irgendwo auf einem Server abzulegen. Du kannst so viele Repositorys wie du willst lokal auf deinem Computer erstellen und verwenden.

Von diesen "Nachteilen" habe ich noch nichts gehört. Ich arbeite täglich mit Subversion. Unter Windows gibt es z.B. *Tortoise SVN*, welches ein fast schon ideales Tool für Subversion ist. Außerdem wird Subversion von vielen IDEs direkt unterstützt. Die breite Unterstützung von Subversion war einer der Gründe dafür.

Subversion ist ideal, wenn man alleine oder mit noch ein paar Entwicklern an einem Programm arbeitet und wenn einer davon der Chef ist. Wenn es mehr werden und alle gleichberechtigt nebeneinander an einem Projekt arbeiten, dann ist ein dezentrales Repository wahrscheinlich die bessere Lösung.

lg
Gerold

@gerold: Die Unterstützung in IDEs ist in der Tat besser bei Subversion, aber ich finde Mercurial auch für "Solo-Projekte" mittlerweile besser. Jedes Arbeitsverzeichnis ist auch gleichzeitig eine Sicherungskopie des gesamten Repositories und ich kann an verschiedenen Rechnern an einem Projekt arbeiten, auch wenn die nicht am Internet hängen und nur gelegentlich Kontakt zu den anderen Rechnern haben. Zum Beispiel der Rechner zuhause, der im Büro, Laptop unterwegs und so weiter. Ich kann auf jedem Rechner jederzeit alle Operationen auf dem Repository durchführen, für die man bei SVN den "Server" braucht, auch wenn der auf *einem* Rechner lokal "läuft". Es geht mit einer verteilten Versionsverwaltung auch ohne Netz zum Beispiel mit einem Repository auf einem USB-Stick.

Für Windows gibt's auch ein "Tortoise HG".

Ideen kommen mir meist beim Bus/Bahnfahren oder Duschen, dort arbeite ich sie auch ein wenig aus. Mehr Planung steckt meist nicht dahinter, deswegen falle ich ab und zu auch mal auf die Schnauze, weil ich etwas nicht bedacht habe. Aber Bildchen malen und mit Stift und Papier planen geht nicht in mein Hirn.

gerold hat geschrieben:Ja, Subversion hat ein zentrales Repository, welches du zum Ein- und Auschecken der Daten brauchst. Aber niemand schreibt dir vor, dieses Repository irgendwo auf einem Server abzulegen. Du kannst so viele Repositorys wie du willst lokal auf deinem Computer erstellen und verwenden.

Ja, es geht. Aber mit DVCS ist selbst das einfacher, weil das anlegen von Repositories zum täglichen Workflow gehört. Zudem wird es kompliziert sobald das lokale Repository dann auf den Server soll.

gerold hat geschrieben:Von diesen "Nachteilen" habe ich noch nichts gehört. Ich arbeite täglich mit Subversion. Unter Windows gibt es z.B. *Tortoise SVN*, welches ein fast schon ideales Tool für Subversion ist. Außerdem wird Subversion von vielen IDEs direkt unterstützt. Die breite Unterstützung von Subversion war einer der Gründe dafür.

Ich arbeite täglich mit Mercurial. Unter Windows (aber auch anderen Systemen) gibt es z.B. *Tortoise Hg* welches ein populäres Tool für Mercurial ist. Mercurial wird ebenfalls von Netbeans und wenn ich mich richtig erinnere von IDEA direkt unterstützt. Eclipse ist da in der Sonderrolle weil das einzige was es direkt unterstützt, CVS ist.

gerold hat geschrieben:Subversion ist ideal, wenn man alleine oder mit noch ein paar Entwicklern an einem Programm arbeitet und wenn einer davon der Chef ist. Wenn es mehr werden und alle gleichberechtigt nebeneinander an einem Projekt arbeiten, dann ist ein dezentrales Repository wahrscheinlich die bessere Lösung.

Was kein Argument für Subversion und gegen Mercurial ist, denn man kann auch mit Mercurial wunderbar ein gemeinsames, zentrales Repository haben. Und bekommt die Vorteile von DVCS frei Haus.

War letztens gezwungen Subversion zu nutzen und ich habe schon ganz vergessen wie wenig mit SVN in den letzten Jahren gefehlt hat.

Es gibt jedoch immer noch einen Bereich wo SVN besser abschneidet als DVCS: Verwaltung von großen Blobs.

Hallo!

Gibt es irgendwo eine deutschsprachige Anleitung/Tutorial oder ein Buch das Mercurial erklärt? Denn auf Englisch habe ich kaum eine Chance, das System dahinter zu verstehen.

lg
Gerold