Projektentwicklungsforum

Du hast eine Idee für ein Projekt?
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

lösung für michael schneiders problem:
von der cmd aus starten, kucken, ob er dann was anzeigt
http://www.cs.unm.edu/~dlchao/flake/doom/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Michael Schneider hat geschrieben:Aber da tatsächlich einiges an Code zusammenkommen dürfte,[...]

Noch eine Frage zu Gobby: ich habe es unter Windows installiert (sogar die Windowsinstallation), aber es startet nicht.
Hallo Michael!

- Ist dir noch nicht aufgefallen, dass dieses Board in die Knie geht, wenn in einem Thema mehrere Beiträge mit ein bischen mehr Code sind? Ich habe sogar den Quelltext von "simplemail" ausgelagert, da man nicht mehr auf einen Beitrag antworten konnte.
Unter diesem Aspekt bin ich nicht unbedingt dafür, dass im "python-forum.de" ein Forum zum Programmieren/Quellcodeaustauschen freigeschaltet wird. Was spricht gegen die Kombination Subversion, Trac und phpBB auf einem Webserver? Diese Tools könnte man sozusagen als Programmierwerkstatt zusammenschalten (untereinander verlinken).

- Subversion: http://subversion.tigris.org/
- TortoiseSVN: http://tortoisesvn.tigris.org/
- Trac: http://trac.edgewall.org/
- phpBB: http://www.phpbb.de/

Gobby-Installationsanleitung: http://darcs.0x539.de/trac/obby/cgi-bin ... ationGuide

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Michael Schneider
User
Beiträge: 569
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Brandenburg

BlackJack hat geschrieben:Ich wollt nur noch mal sagen das man nicht wirklich Quelltext mit einem Forum "verwalten" möchte. Nimm dazu lieber eine Versionsverwaltung.
Hi BlackJack,

was verstehst Du unter "verwalten"? Der Code soll dort veröffentlicht werden, so dass andere etwas davon lernen oder Vorschläge zur Verbesserung machen können. Er soll aber nicht in den Foren gelagert werden, bis das Projekt abgeschlossen ist, sondern wird, sobald er als i.O. gilt, in den Gesamtprojektcode oder ein Verwaltungssystem eingepflegt.
Prinzipiell hätte ich nichts dagegen, die Code gleich in einer Versionsverwaltung unterzubringen und im Forum nur die markanten Passagen zu quoten und zu diskutieren.

Ich bin mir aber nicht sicher, dass das dann bei allen Usern mit dem Updaten richtig (und einfach) funktioniert und man nicht gerade dann die Übersicht verliert. Ich bin aber immer für eure Meinungen offen.

Grüße,
Michael
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Zu Gobby... Du must noch zwei Pakete installieren: GTK und GTKmm! Steht unter:
http://darcs.0x539.de/trac/obby/cgi-bin ... ationGuide

Und schau dir mal trac näher an, da hat man nämlich so einiges was für die Planung wichtig ist!

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Hi Michael!

Ich glaube, du hast eine falsche Vorstellung davon, was so ein Versionsverwaltungssystem macht. Deshalb hier ein paar Worte über Subversion (SVN).

Du kannst bei dir lokal auf der Festplatte einen Ordner erzeugen und in diesem Ordner dein Programm entwickeln. Am besten schön aufgeteilt -- also einzelne zusammengehörende Bereiche in eigene Module aufteilen. Das erleichtert später auch die Zusammenarbeit mit anderen Entwicklern.

Dann achtest du auch noch darauf, dass Funktionen als abgeschlossene Einheit arbeiten. Also keine globale Variablen erwarten.

Parameter --> Funktion --> Rückgabe

So lassen sich einzelne Funktionen unabhängig voneinander TESTEN. Das ist ziemlich wichtig. Damit bestimmst du wie sich eine Funktion verhalten muss und kannst das immer wieder nachprüfen.

Und jetzt kommt SVN ins Spiel. Du erstellst dir auf einem Server ein Subversion-Repository. In diesem Repository erstellst du drei Basisordner ``trunk``, ``tags`` und ``branches``.

Der Ordner ``trunk`` ist für den aktuellen Entwicklungszweig. Hier befindet sich immer die aktuellste Programmrelease.

Der Ordner ``tags`` ist für die einzelnen Zwischenstände. Jedes mal, wenn du eine Programmrelease veröffentlichst, dann speicherst du hier in einem eigenen Unterordner (mit Versionsbezeichnung) den Quellcode, zum Stand des Programmreleases. Damit hast du immer die Möglichkeit, auf den exakten Stand eines Programmreleases zurück zu greifen. Noch dazu kostet das kaum Speicherplatz, da SVN beim Kopieren keine Kopie, sondern einen Link zu einer Dateiversion erstellt.

Der Ordner ``branches`` ist für ausgelagerte Entwicklungen. Es ist so, dass man meistens untereinander ausmacht, dass in den ``trunk``-Ordner nur dann Code eingeckeckt werden darf, wenn dieser kompilierbar oder im Fall von Python ausführbar/testbar ist. Das ist wichtig, damit andere Programmierer am Code arbeiten können und dafür funktionierenden Code zur Verfügung haben. Wenn du also ein Feature einprogrammieren möchtest, für das du viele Tage brauchst und in dieser Zeit das Programm nicht ausführbar/testbar sein wird und du in dieser Zeit nicht auf die Versionsverwaltung verzichten möchtest (ist ja auch eine gute Backupstrategie), dann erstellst du dir im ``branches``-Ordner einen neuen Ordner, ganz speziell nur für dieses Feature. Dann kopierst du dir den Inhalt des ``trunk``-Ordners in diesen neuen Ordner und arbeitst an diesem Feature nur in diesem ``branches``-Unterordner. Dazu stellst du deine lokale Arbeitskope so um, dass beim **Commit** (das ist der Vorgang, wenn du deinen Quellcode ins Repository zurück speicherst) nicht in den ``trunk``-Ordner sondern in den speziellen ``branches``-Unterordner gespeichert wird.
Ist das Feature fertig entwickelt, dann stellst du wieder auf ``trunk`` um und pflegst die Änderungen, die inzwischen im ``trunk``-Ordner gemacht wurden, in deinen **Branch** ein (merge). Läuft bei dir dann das Programm, inklusive deiner und den Änderungen der anderen Programmierer, dann kannst du den neuen Stand wieder in den ``trunk``-Ordner commiten.

Du kannst jeden Entwicklungsstand, der je in das SVN eingepflegt wurde, wiederherstellen und so Fehler wieder ausbessern. So ist es kein Problem, wenn jemand mal einen Pfusch gebaut hat. Auch lässt sich schön nachverfolgen, was von wem am Quellcode in welcher Datei geändert wurde. So lässt sich schnell herausfinden, welche Änderung am Quellcode schuld ist, warum etwas nicht mehr so wie gewünscht funktioniert.

Beim Commit muss jeder einen Kommentar übermitteln. Die gesammelten Kommentare beschreiben dann den Verlauf der Entwicklung eines Programmes. Das ist auch der Grund, weshalb ich für jedes Programm ein eigenes SVN-Repository verwalte.

Als Entwickler der vor hat gemeinsam mit anderen Entwicklern ein Programm zu programmieren, ist es, meines Erachtens, ein absolutes Muss, sich mit Subversion zu beschäftigen.

Auch wenn man alleine ist und nicht gemeinsam programmiert, ist so eine Versionsverwaltung ein wahrer Segen. Es ist schon einige Male vorgekommen, dass ich dankend wieder auf eine vorhergehende Version eines Programmes zurückgegriffen habe, da ich mich beim Programmieren verrannt oder schlicht eine Datei versehentlich gelöscht habe.

Genausoviel, wenn nicht noch mehr dieser nützliche Dinge kann ich auch über Trac schreiben. SVN ist gut, aber in Verbindung mit Trac ist es spitze! Trac verbindet SVN mit einer Projektverwaltung (Ticketsystem, Timeline, Roadmap) und einem Wiki. Vom Wiki aus lassen sich Links zu Tickets, zu einzelnen Zeilen in einer Quellcodedatei und zu Changesets erstellen. Sogar die Auflistung der einzelnen Tickets (=ToDo-Anweisungen oder Fehlerberichte) kann angepasst und über das Wiki aufgerufen werden. Quellcode mit Syntaxhighlighting, reStructured Text usw.

Klar -- man braucht schon einige Tage um sich in so ein System einzuarbeiten, aber das ist es auf jeden Fall wert.

Wenn du jetzt noch, zum zusätzlichen Koordinieren und gemeinsamen Besprechen von Codeteilen, ein Forum heranziehst, dann hast du eine wunderschöne Programmfabrik, die Fehler verzeiht und mit der die Zusammenarbeit an einem Programm Spaß macht.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
djax
User
Beiträge: 1
Registriert: Samstag 6. Oktober 2007, 10:06

Hallo Gerold,

eine schöne Beschreibung, die du da geliefert hast.
Habe mich auch gestern mal an svn gesetzt. Sehr hilfreich die ganze Sache.
Eine Frage drängt sich mir jedoch auf, da das ganze System auf den ersten Blick, was die Filehierarchie angeht für mich noch undurchsichtig ist.
Du hast ja recht ausführlich geschrieben, dass man das ganze in drei Unterordner aufteilen kann. Benutzt man jetzt ein Repos für genau ein Projekt oder legt man eins an und verwaltet damit mehrere Projekte?

Gruß Micha
BlackJack

Das bleibt völlig Dir überlassen.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:Das bleibt völlig Dir überlassen.
Es ist auch von Projekt zu Projekt unterschiedlich.

Pocoo nutzt für alle Unterprojekte das gleiche Repository, ich selbst habe mehrere Projekte und ein Projekt für alles ebenso in einem einzigen Repository.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Leonidas hat geschrieben:Pocoo nutzt für alle Unterprojekte das gleiche Repository, ich selbst habe mehrere Projekte und ein Projekt für alles ebenso in einem einzigen Repository.
Das ist Geschichte ;-)
TUFKAB – the user formerly known as blackbird
Antworten