Wenn das Projekt "fertig" ist...

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Wenn das Projekt "fertig" ist...

Beitragvon keppla » Montag 14. Januar 2008, 14:24

Hallo Forum!
Mich interessiert, was ihr für Prozesse/Hilfsmittel für eure Projekte ausserhalb des reinen Codierens benutzt,

Wie erstellt ihr die Doku, die nicht-api-Doku, wie macht ihr Releases, wie testet ihr die Releases, wie macht ihr die Projektwebseite, kurz, all die Dinge, von denen man sich als naiver Programmierer denkt: "ok, das Programm ist fertig, jetzt noch kurz...".

Besonders interessiert bin ich an der Automatisierung dieser Prozesse.
Danke schonmal im voraus.
fred.reichbier
User
Beiträge: 155
Registriert: Freitag 29. Dezember 2006, 18:27

Beitragvon fred.reichbier » Montag 14. Januar 2008, 14:41

Für die Doku benutze ich epydoc. Docstrings sind da einfach das Flexibelste.
Die restlichen Skripte schreibe ich eigentlich alle selbst. Ich habe aber auch schonmal für eine Website Globby verwendet :)
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Re: Wenn das Projekt "fertig" ist...

Beitragvon gerold » Montag 14. Januar 2008, 14:46

keppla hat geschrieben:Wie erstellt ihr die Doku, die nicht-api-Doku, wie macht ihr Releases, wie testet ihr die Releases, wie macht ihr die Projektwebseite

Hallo keppla!

Ich verwalte meine Projekte in Subversion-Repositories http://subversion.tigris.org/. Jedes größere Projekt bekommt ein eigenes Repository -- ist ja schnell erstellt so etwas. Unter Windows verwalte ich die Daten mit TortoiseSVN http://tortoisesvn.tigris.org/. Die Befehle ``svn update`` und ``svn commit`` habe ich in CMD-Dateien, so dass ich mit einem einfachen Doppelklick einen ganzen Ordner aktualisieren kann.

Aufbauend auf die SVN-Repositories bekommt jedes größere Projekt eine eigene Trac-Website. Das eingebaute Wiki verwende ich um Informationen zu protokollieren. --> Aufbau des Programmes, Informationen über Kunden, Telefonnummern, Adressen, usw.. Also alles was ich an Informationen brauche um ein Programm fertig stellen zu können. Das ist auch die Schnittstelle zwischen mir (Tirol) und den Leuten in Wien. In Wien werden die für mich wichtigen Informationen zusammengetragen und ich programmiere in Tirol.

Im Trac stelle ich mir Tickets mit den Eckpunkten und Roadmaps zusammen. So habe ich immer im Überblick, was bis zu welchem Milestone fertig sein soll und kann mir meine Arbeit schön einteilen. Außerdem ist es befriedigend, wenn die Tickets von Tag zu Tag weniger werden.

Die Programmhilfe schreibe ich im reStructuredText-Format in einem Unterordner des Programms. Daraus lasse ich automatisiert HTML-Seiten erstellen. In dieser Hilfe stehen dann Erklärungen, Kommandozeilenparameter, Einstellungsparameter, usw. genau erklärt. Diese reStructuredText-Dateien kennzeichne ich besonders für Trac als reStructured-Text-Dateien. Und damit werden diese im Trac schön formatiert angezeigt.

Nachdem das Programm fertig ist, werden die Tickets für Fehlermeldungen und Programmwünsche genutzt. Im Wiki gibt es dann auch noch einen Bereich "fehlerdatenbank". In diesem Bereich werden vom Support-Team Fehler, Probleme und deren Lösungen protokolliert. So entwickelt sich das Trac im Laufe des Programmlebens zusätzlich zu einer KnowHow-Datenbank für den Support.

Dass ich mit meiner Firma per OpenVPN verbunden bin, sollte ich vielleicht noch dazu schreiben. Und um die Sicherung der Repositories kümmert man sich natürlich in Wien.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

Beitragvon BlackVivi » Montag 14. Januar 2008, 14:55

Was mich noch interessieren würde:

Wenn ich etwas fertig programmiert habe und es nun bspw. an einen Freund verteilen möchte, wie mach ich das am besten? Das ich'ne EXE mit py2exe und seinen Konsorten erstellen kann ist mir klar, aber wenn ich die Pythonsource ausliefern möchte... Was wäre am besten? Ein setup.py schreiben, mit irgendeinem Programm einen installer bauen der dann Python im Bedarf mitinstalliert oder was?...

Und wie sieht das unter Linux aus? Das es da Paketformate gibt und wie man das unterscheidet weiß ich, aber wie sieht die pure "Source" aus, die man beispielsweise für Pakete dann verwenden kann? Muss ich da irgendwas beachten oder kann ich einfach sozusagen alle meine Module zusammenschmeißen?
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Montag 14. Januar 2008, 15:41

BlackVivi hat geschrieben:Wenn ich etwas fertig programmiert habe und es nun bspw. an einen Freund verteilen möchte, wie mach ich das am besten?

Hallo BlackVivi!

Ich schreibe meist eine HTML-Datei (natürlich mit reStructuredText) mit der Installationsanleitung. Diese kommt auf die CD mit drauf und wird LIESMICH.HTM/README.HTM bzw. LIESMICH.TXT/README.TXT genannt.

Das sieht dann ungefär so aus:

[code=]Installation unter Windows 2000/XP
=====================================

- Als Benutzer mit Administratorrechten anmelden

- Python herunterladen und mit Doppelklick installieren
- http://python.org/ftp/python/2.5.1/python-2.5.1.msi

- Computer neu starten (wäre keine schlechte Idee)

- Wieder als Benutzer mit Administratorrechten anmelden

- pywin32 herunterladen und mit Doppelklick installieren
- http://downloads.sourceforge.net/pywin32/pywin32-210.win32-py2.5.exe

- wxPython herunterladen und mit Doppelklick installieren
- http://downloads.sourceforge.net/wxpython/wxPython2.8-win32-unicode-2.8.7.1-py25.exe

- Programmsetup (das_programm_setup.exe) mit Doppelklick installieren[/code]
Meine Erfahrung ist die, dass die Leute nicht so blöd sind, dass sie damit nicht klar kommen würden. Die meisten Leute möchten eine klare Anleitung, so dass sie etwas einfach installieren können. Es macht ihnen aber nichts aus, wenn die Installation aus mehreren Programmen besteht. Dass die Leute nur mit **einer** Setupdatei klar kommen und es nicht schaffen, mehrere Installationsprogramme hintereinander auszuführen ist ausgemachter Blödsinn. Aber es braucht eine Anleitung dafür. Das ist wichtig. Und wenn ein Programm per Post verschickt wird, dann muss diese Anleitung auch als Beipackzettel mit dabei liegen. Damit fahren wir ziemlich gut.

Alle benötigten Dateien für das Programm fasse ich derzeit noch mit InnoSetup http://www.jrsoftware.org/isinfo.php (ich überlege aber derzeit auf InstallJammer http://www.installjammer.com/ TIPP! umzusteigen) in ein Setupprogramm zusammen. Damit wird das Programm auch ins Startmenü eingetragen und der Windows-Benutzer fühlt sich wie zuhause. :-) GUI-Programme lasse ich natürlich mit *pythonw.exe* starten, damit das Konsolenfenster nicht angezeigt wird.

Kleine Python-Pakete, wie z.B. pyYaml oder pyODBC usw., lasse ich meistens von Innosetup mitinstallieren. Die Installationsdateien (EXE) lasse ich damit schlicht und einfach nacheinander ausführen. Eine weitere Integration ist mir nicht wichtig, da es total egal ist, wenn diese Installationen mehrmals hintereinader ausgeführt werden.

mfg
Gerold
:-)

PS: InstallJammer http://www.installjammer.com/ soll plattformübergreifende Setups erstellen können. :D
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

Beitragvon BlackVivi » Montag 14. Januar 2008, 15:47

Hallöschen Gerold :3,

reStructuredText ist wirklich unglaublich gut und sollte bei Python Standard werden. Eine Bezeichnungssprache die man ganz einfach auch ohne irgendwelches Parsen super lesen kann... Hab ich mir schon immer gewünscht.

Dein Weg scheint gut zu sein, gefällt mir. (Der Vorteil an Linux ist übrigens das man bei Linux immer davon ausgehen kann, das die Leute ungefähr wissen was sie tun. Zumindest war's mal so...) Ich werd's wohl so machen...

(Wenn Pocoo mal fertig wird, hoff' ich das sie statt BBCode irgendwie reStructuredText benutzen :3)
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Re: Wenn das Projekt "fertig" ist...

Beitragvon veers » Montag 14. Januar 2008, 16:13

Zur Verwaltung des Sourcecodes verwende ich git.
Zum erstellen der Source Distributionen / installer verwende ich distutils.
Für die Windows Installationen distutils + nsis + ein paar Batchfiles.
Für die Unittests verwende ich das unittest Modul von Python.
Für das erstellen der User Dokumentation habe ich in der Vergangenheit meinen eigenen kleines Format/Script verwendet welches ich ursprünglich in Ruby geschrieben habe. Werde aber vermutlich in Zukunft reST verwenden.
Websites für kleinere Projekte schreibe ich als statisches HTML in einem Texteditor. Die Lanshark Website habe ich mit Mako sowie einem kleinen Script statisch generiert. Ich bin mir jedoch noch nicht ganz sicher ob der Ansatz toll ist ;)
My Website - 29a.ch
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
fred.reichbier
User
Beiträge: 155
Registriert: Freitag 29. Dezember 2006, 18:27

Beitragvon fred.reichbier » Montag 14. Januar 2008, 16:42

Achja, das Revisionskontrollsystem habe ich vergessen ;) Dank SourceForge ist eines jedenfalls Subversion, wobei ich auch sehr gerne Bazaar einsetze. Das lässt sich sogar auf meinem Shared-Webspace ohne Python und Root-Access aufsetzen, und das ist praktisch. Distributed VCS sind mir mittlerweile lieber als Server-Client-Lösungen wie SVN, da habe ich einfach weniger Aufwand. Git und Mercurial wollte ich aber auch mal ausprobieren.

Gruß Fred
Zuletzt geändert von fred.reichbier am Montag 14. Januar 2008, 16:44, insgesamt 1-mal geändert.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Montag 14. Januar 2008, 17:02

Danke erstmal für das reichliche Feedback!

Habt ihr die tools irgendwie verbunden?
Ich bin zZ bei vhost,svn,trac, dokumentation gucke ich gerade, und ich stelle fest, dass ich eine verhältnismäßig hohe fehlerquote z.B. bei releases und versionierung habe.
Beispielsweise will ich will ein release machen, und vergesse, die versionsvariable hochzuzählen, oder mache das, setze sie aber nicht im trunk auf "dev" zurück. Ich hätte auch gerne sowas wie die aktuelle revision im code, oder noch besser, nur ein knopfdruck (oder eine zeile ssh) und das nächste release ist fertig.
Nur hab ich das Gefühl, alles, was ich selber Skripte, läuft genau einmal, und beim nächsten mal hat sich so viel geändert, dass ich es neu schreiben muss.
Habt ihr da ähnliche Erfahrungen, oder mach ich das nur ungeschickt?
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Montag 14. Januar 2008, 17:25

keppla hat geschrieben:versionsvariable

Hallo keppla!

Ich vermische die SVN-Revisionen nicht mit meinen Programm-Releases. SVN hat seine eigene Zählung. Diese rühre ich nicht an.

Ich habe im Programmordner die Datei "version.txt". In dieser steht die Programmversion drinnen. Die Programmversion setze ich händisch höher, bevor ich an einer Änderung im Programm beginne.

version.txt:
[code=]0.0.1[/code]
Die letzte Zahl wird hochgezählt. Sobald sich etwas Entscheidendes im Programm getan hat, wird die mittlere Zahl um 1 erhöht und die letzte zahl wird wieder auf 1 zurück gesetzt. Das nehme ich auch zum Anlass, um nach dem "svn commit", im Subversion-Repository eine neue Kopie als "Tag" abzulegen.

Dieses Schema verwende ich auch in der *history.rst*. So eine *history.rst*-Datei sieht bei mir in etwa so aus:
[code=]=======
History
=======

In dieser Datei stehen die erledigten Aufgaben. Diese werden frei
eingetragen oder es handelt sich um erledigte Aufgaben aus der ToDo-Liste.
Das Format dieser Datei ist reStructuredText.

Die Reihenfolge der History-Einträge bestimmt die Reihenfolge
in der die Aufgaben erledigt wurden.
Ganz **oben** sind die **neuesten**, erledigten Aufgaben und
ganz unten sind die ältesten, erledigten Aufgaben.


==============
Version 1.2.12
==============

- Durch die Umstellung auf Python 2.5 wurde der Befehl
``locale.format("Betrag: %.2f", amount)`` nicht mehr akzeptiert. Dieser wurde
nach ``"Betrag: " + locale.format("%.2f", amount)`` umgeändert.


==============
Version 1.2.11
==============

- BKS-Server: STARTCOMMAND und STOPCOMMAND eingeführt.
Wenn beim Starten des BKS-Client aus irgendeinem Grund die
Session nicht erstellt werden konnte, dann wird dem Kassier
angeboten, den BKS-Server neu zu starten.


==============
Version 1.2.10
==============

- **Fixed**: Ein Unicode-Fehler beim Schreiben der INI-Datei.
Bei Leitungsstörung wird der String "LEITUNGSSTÖRUNG" übergeben.
Dieser wurde nicht ohne Fehler in die INI-Datei geschrieben.

...[/code]
Diesen Text, den ich hier bei jeder Änderung eintrage, verwende ich auch als Text für die Bemerkungen bei "svn commit".

Ein typischer SVN-Baum sieht bei mir in etwa so aus:
[code=]/programmname/
/branches/
/tags/
/0.1.1/
datei1
datei2
version.txt
history.rst
/0.2.1/
datei1
datei2
version.txt
history.rst
/1.1.1/
datei1
datei2
version.txt
history.rst
/1.2.1/
datei1
datei2
version.txt
history.rst
/trunk/
datei1
datei2
version.txt
history.rst[/code]
Die SVN-Tags sind immer eine Kopie vom Trunk-Ordner. Diese erstelle ich mit dem RepoBrowser des TortoiseSVN. Aber man könnte dafür natürlich auch das Kommandozeilenprogramm "svn" verwenden.

mfg
Gerold
:-)

PS: Ich spreche hier von Programmen und nicht von Progrämmchen.
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Beitragvon EnTeQuAk » Montag 14. Januar 2008, 21:08

fred.reichbier hat geschrieben:Ich habe aber auch schonmal für eine Website Globby verwendet :)

Das hört man natürlich sehr gerne, dich wird es dann wohl freuen das Globby bald wieder Fart aufnimmt.


Aber nun mal zum Thema:

Ich persönlich benutze vergleichsweise wenig neben dem Programmieren. Zur Versionsverwaltung Mercurial und SVN. Dokumentationen erstelle ich in der Regel nach den Formatierungen von rst von den docutils.

Die werden in externe Text-Dateien gepackt und später entsprechend gerendert. Gerne verwende ich dazu auch angepasste kleine Scripte, wie sie auch in den Pocoo-Repositories zu Hauf rumliegen.

API-Dokumentationen packe ich meißtens auch in externe Text-Dateien -- oft zusammen mit den normalen Dokumentationen.
Epydoc & co. verwende ich nicht, ich finde die volle Kontrolle irgentwie besser. Meißt packen die Sachen in die Doku, die ich persönlich nie dokumentiert hätte (interne hilfsmethoden etc.).

Projektwebseiten erstelle ich wenn denn mit Globby -- Beziehungsweise richte eine neue Seite auf einer sich gerade in Entwicklung befindlichen Seite ein, die bald unter http.//projects.webshox.org zu finden sein wird. Aber das ist vorerst Zukunftsgeschichte ;)

Zur verwaltung von Projekten, Bug-Reports, Feature-Requests etc. verwende ich Trac, ansonsten wars das eigentlich an zusätzlichen Dingen.

Was übrigens das Testen angeht, das wird nach einem Release vorerst nicht gemacht. Entweder konzentriere ich mich komplett aufs nächste Release und achte nur auf Fehlermeldungen von Benutzern oder suche selber Bugs im Release -- Je nach Zeitaufwand und Projekt variiert das stark.


MfG EnTeQuAk
lunar

Beitragvon lunar » Montag 14. Januar 2008, 22:01

EnTeQuAk hat geschrieben:
fred.reichbier hat geschrieben:Ich habe aber auch schonmal für eine Website Globby verwendet :)


API-Dokumentationen packe ich meißtens auch in externe Text-Dateien -- oft zusammen mit den normalen Dokumentationen.
Epydoc & co. verwende ich nicht, ich finde die volle Kontrolle irgentwie besser. Meißt packen die Sachen in die Doku, die ich persönlich nie dokumentiert hätte (interne hilfsmethoden etc.).

API-Docs sind bei Python sowieso völlig sinnlos. In den API-Docs steht auch nur das drinnen, was die Docstrings sagen, und die kann ich auch mit ipython einsehen (und dort kann ich das dann auch gleich ausprobieren).

Einem Entwickler hilft ein gut gemachtes Tutorial, dass kurz, aber gut erklärt, wie man die Features eines Pakets anwendet, viel mehr, da man so die wichtigsten Klassen, Methoden und Funktionen auf einen Blick sieht, ohne sie erst unter den Unmengen uninteressanter API-Docs herausfischen zu müssen.

Wenn der Entwickler auf HTML-API-Docs steht, kann er die immer noch selbst erzeugen (ob nun per epydoc oder pydoc). Ein gutes Tutorial kann man allerdings nicht so schnell selbst schreiben.

Ich persönlich nutze folgendes für das "Drumherum":
  • git als VCS
  • ein lokales trac als Bugtracker
  • setuptools für die Installer (plus Installationsanleitung für Windowsianer)
  • unittests per "unittest"
  • ReST für Dokumentation
  • Wenn eine Website später her muss, reicht das lokale Trac mit ein bisschen Content gefüllt völlig aus.


Der Vorteil an der Dokumentation per ReST ist, dass man sie überall eingliedern kann. Die meisten Wiki's können ReST, die meisten Template-Engines können ReST und trac kann's auch. Man spart sich also das Pflegen separater Dokumentation für Website und Paket.

Ich habe für ein Projekt mal py2exe genutzt, was aber dazu geführt hat, dass das Erstellen eines funktionierenden Setup-Skripts länger gedauert hat als das Programmieren selbst. Mittlerweile bietet Riverbank Computing aber vollständige PyQt4 Installer an (die Qt4 und mingw gleich mitbringen), so dass sich die PyQt4 Installation von drei auf einen Installer reduziert, und damit eigentlich annehmbar für den User ist.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Dienstag 15. Januar 2008, 14:02

gerold hat geschrieben:
keppla hat geschrieben:versionsvariable

Ich vermische die SVN-Revisionen nicht mit meinen Programm-Releases. SVN hat seine eigene Zählung. Diese rühre ich nicht an.

Vermischen wollte ich die auch nicht.
Ich hätte es nur gerne so, dass jemand, der sich seinen code auscheckt, im code explizit die revision stehen hat, damit ich sie in "about" oder sonstwo anzeigen kann, da ich schon öfters den fall hatte, dass der user mir nicht genau sagen konnte, vor wie langer zeit er das Programm ausgecheckt hatte, wenn er Fehler berichtet.
Nur leider hab ich da bis jetzt keine gute Lösung für gefunden, svn-keywords funktionieren nur auf geänderten dateien, und svn-hooks durften, so weit ich das verstanden habe, den commit-code nicht ändern.

Ich habe im Programmordner die Datei "version.txt". In dieser steht die Programmversion drinnen. Die Programmversion setze ich händisch höher, bevor ich an einer Änderung im Programm beginne.

Da scheine ich zu trottelig zu sein, oder die Tatsache, dass es ein Hobbyprojekt ist sorgt dafür, dass ich da hektischer bin.
Bei mir würde ein release aus
-testen
-kopie in "tags"
-version ändern
-diverse builds (eggs, etc) erzeugen
-diese auf der projektpage veröffentlichen
hinauslaufen, und irgendwie scheine ich da immer den einen oder anderen Schritt zu vergessen.

[code=]0.0.1[/code]
Die letzte Zahl wird hochgezählt. Sobald sich etwas Entscheidendes im Programm getan hat, wird die mittlere Zahl um 1 erhöht und die letzte zahl wird wieder auf 1 zurück gesetzt. Das nehme ich auch zum Anlass, um nach dem "svn commit", im Subversion-Repository eine neue Kopie als "Tag" abzulegen.


also released du vom patch x.y.z -> x.y.z+1 nicht?
Sind solche changes nach deiner Definition nichts veröffentlichenswertes?

Dieses Schema verwende ich auch in der *history.rst*. So eine *history.rst*-Datei sieht bei mir in etwa so aus:
...
Diesen Text, den ich hier bei jeder Änderung eintrage, verwende ich auch als Text für die Bemerkungen bei "svn commit".

Liesse sich dann nicht diese Datei aus den commitmessages erstellen? Oder spricht da etwas (wie z.B. starke manuelle Eingriffe) dagegen?

Gerne verwende ich dazu auch angepasste kleine Scripte, wie sie auch in den Pocoo-Repositories zu Hauf rumliegen.

sofern deine Lizenz das hergibt (gilt deine BSD-Wahl auf für die Scripte?) würde ich mich da gerne bedienen.

Rest werde ich wohl auch nutzen, das scheint mir sehr angenehm. Dass api-docs nicht viel bringen, kann ich auch so nach und nachvollziehen. Ist wohl eine Nachwirkung von Java bei mir, dass ich die schreiben will.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Dienstag 15. Januar 2008, 16:26

Hallo keppla!

keppla hat geschrieben:Ich hätte es nur gerne so, dass jemand, der sich seinen code auscheckt, im code explizit die revision stehen
hat

Dafür hat er ja die Textdatei "version.txt" im Programmordner mit drinnen stehen.

keppla hat geschrieben:damit ich sie in "about" oder sonstwo anzeigen kann

Dafür lese ich immer die erste Zeile der "version.txt"-Datei aus.

keppla hat geschrieben:also released du vom patch x.y.z -> x.y.z+1 nicht?

Nehmen wir an, ich arbeite an einer kleinen Änderung. Dann führe ich zuerst mal "svn update" aus. Dann erhöhe ich die Version in der "version.txt". Danach arbeite ich an den Änderungen, welche ich sofort danach in die Datei "history.rst" eintrage. Zwischendurch, wenn das Programm wieder lauffähig ist, führe ich ein "svn commit" aus. Dafür öffne ich mir die "history.rst" und kopiere mir den Text in die Zwischenablage und füge diesen als Bemerkung für das "svn commit" ein. Dabei kontrolliere ich noch, ob ich Umlaute oder Sonderzeichen mit drinnen habe und lösche/ändere sie. Ab und zu kürze ich den Text noch ein wenig. Als Editor für diese Revisions-Bemerkungen habe ich mir den Notepad von Windows in den SVN-Einstellungen eingestellt. Da ich den sonst nie für irgendetwas verwende. Ansonsten müsste ich nach dem Eintragen der Bemerkungen jedes mal meinen Haupteditor schließen, damit SVN die Änderung übernimmt.

Da in Wien alle Bescheid wissen, wenn ich an einem Projekt arbeite, pfuscht mir auch keiner dazwischen und ich muss mich nicht ums Mergen von Änderungen anderer Programmierer kümmern. Ich führe also immer wieder zwischendurch einen "svn commit" durch. So kann ich Änderungen gezielt wieder Rückgängig machen, falls ich einen Blödsinn gebaut habe. ;-)

Bei dieser Entwicklung handelt es sich immer um den Trunk-Zweig. Also den Repository-Zweig, der nur für Entwickler interessant ist. Ein Kunde wird niemals von mir etwas aus dem Trunk-Zweig bekommen. Komme ich in die Lage, dass ein Kunde das neueste Programm braucht, dann erstelle ich zuerst einen Tag mit der Kopie des Trunk-Ordners.

keppla hat geschrieben:
*history.rst*

Liesse sich dann nicht diese Datei aus den commitmessages erstellen? Oder spricht da etwas (wie z.B. starke manuelle Eingriffe) dagegen?

Das war es mir noch nie wert, darüber nachzudenken. Ich habe ja die Zwischenablage und die *history.rst* ist oft viel detaillierter als die Revisions-Bemerkungen. Und auch umgekehrt.

In der *history.rst* steht Wissenswertes über die Änderung am Programm. Und in den Revisions-Bemerkungen steht Wissenswertes über die Änderungen am Repository. Z.B. steht dort drinnen, dass ich einen neuen "tag" mit einer neuen Programm-Release erstellt habe und vielleicht auch warum ich das getan habe. Z.B. steht dort drinnen, wenn ein neuer Branch erstellt wird und für was der gut ist. Das sind alles Informationen die das Programm nicht betreffen. Das sind Informationen über die Änderungen am Repository. Deshalb mische ich das auch nicht. Vielleicht habe ich auch vergessen, eine Datei einzuchecken. Dann hole ich das nach und schreibe eine Revisions-Bemerkung. Das ist aber kein Grund, so etwas in die *history.rst* zu schreiben.

Was ich eigentlich damit sagen möchte: Programmversion und Repository-Revision sollten NICHTS miteinander zu tun haben.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Dienstag 15. Januar 2008, 17:05

gerold hat geschrieben:Dafür hat er ja die Textdatei "version.txt" im Programmordner mit drinnen stehen.

wo man bei jedem commit von hand die reversion ändert?
ich verstehe schon, dass getrennt wird zwischen release und svn, und die releases per hand versioniert werden.
Vielleicht drücke ich mich zu unklar aus, ich hätte gerne im about bei einem release "version 2.3.5" und bei einem checkout "dev, revision 23" stehen.
Eben weil bei mir auch user die svn-versionen auschecken.

keppla hat geschrieben:also released du vom patch x.y.z -> x.y.z+1 nicht?

[erklärung]
Ein Kunde wird niemals von mir etwas aus dem Trunk-Zweig bekommen. Komme ich in die Lage, dass ein Kunde das neueste Programm braucht, dann erstelle ich zuerst einen Tag mit der Kopie des Trunk-Ordners.


Ok, dann war das das Missverständnis. Ich bin davon ausgegangen, dass der Kunde immer die neuste Version haben sollte. Ich vergleiche vermutlich ungünstig, mein Programm hat ja keinen speziellen Kunden, sondern ist eher "massenware", somit will ich eigentlich jeden Patch direkt veröffentlichen.

keppla hat geschrieben:
*history.rst*

Liesse sich dann nicht diese Datei aus den commitmessages erstellen? Oder spricht da etwas (wie z.B. starke manuelle Eingriffe) dagegen?

Das war es mir noch nie wert, darüber nachzudenken. Ich habe ja die Zwischenablage und die *history.rst* ist oft viel detaillierter als die Revisions-Bemerkungen. Und auch umgekehrt.

Ok, das was ich mit starke manuelle Eingriffe meinte, das eine müsste händisch zum anderen werden.

Danke für die ausführliche Erläuterung.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder