Seite 1 von 1

Wenn das Projekt "fertig" ist...

Verfasst: Montag 14. Januar 2008, 14:24
von keppla
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.

Verfasst: Montag 14. Januar 2008, 14:41
von fred.reichbier
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 :)

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

Verfasst: Montag 14. Januar 2008, 14:46
von gerold
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
:-)

Verfasst: Montag 14. Januar 2008, 14:55
von BlackVivi
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?

Verfasst: Montag 14. Januar 2008, 15:41
von gerold
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: Alles auswählen

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
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

Verfasst: Montag 14. Januar 2008, 15:47
von BlackVivi
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)

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

Verfasst: Montag 14. Januar 2008, 16:13
von veers
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 ;)

Verfasst: Montag 14. Januar 2008, 16:42
von fred.reichbier
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

Verfasst: Montag 14. Januar 2008, 17:02
von keppla
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?

Verfasst: Montag 14. Januar 2008, 17:25
von gerold
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: Alles auswählen

0.0.1
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: Alles auswählen

=======
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.

...
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: Alles auswählen

/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
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.

Verfasst: Montag 14. Januar 2008, 21:08
von EnTeQuAk
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

Verfasst: Montag 14. Januar 2008, 22:01
von lunar
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.

Verfasst: Dienstag 15. Januar 2008, 14:02
von keppla
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: Alles auswählen

0.0.1
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.

Verfasst: Dienstag 15. Januar 2008, 16:26
von gerold
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
:-)

Verfasst: Dienstag 15. Januar 2008, 17:05
von keppla
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.

Verfasst: Dienstag 15. Januar 2008, 17:14
von CM
keppla hat geschrieben: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,
Was spricht dagegen subversion properties - oder etwas Gleichartigem bei Deinem favorisierten Versioningsystem? Ich verwende das zumindest, um sicherzustellen, daß Revisionsnummer, Datum und Author der letzten Revision im File stehen. Natürlich, Gerold hat recht, die svn-Revisionsnummer ist nicht dasselbe wie der Projektstatus, der in einer Versionsnummer wiedergegeben wird. Die muß man schon per Hand setzen. Ich zum Beispiel bin viel konservativer beim Zählen als er ;-) und einem Programm kann man schlecht beibringen die Tragweite einer Revision numerisch zu schätzen.

Was Anleitungen angeht: Für mich sind Beispiele und eine direkte Sprache wichtig, eine verquastete Anleitung ist so viel wert wie gar keine: Sie wird nämlich nicht gelesen.

Gruß,
Christian

Verfasst: Dienstag 15. Januar 2008, 17:28
von gerold
keppla hat geschrieben:ich hätte gerne im about bei einem release "version 2.3.5" und bei einem checkout "dev, revision 23"
Hallo keppla!

Du kannst SVN-Keywords einsetzen um automatisch Informationen über das Repository in die Datei schreiben zu lassen. Diese musst du aber vorher aktivieren.

http://blog.wochele.de/archives/10-Subv ... words.html

http://subversion.tigris.org/faq.html#v ... -in-source

Du kannst dir eine CMD-Datei schreiben, mit der du dein Programm eincheckst. Zuerst ersetzt du damit irdendeinen "Version-Platzhalter" durch den Text aus "version.txt" und danach führst du "svn commit" aus. Ich verwende CMD-Dateien um dabei auch gleich die HTML-Seiten für die Hilfe generieren zu lassen, bevor diese ins Repository übernommen werden.

mfg
Gerold
:-)

Verfasst: Dienstag 15. Januar 2008, 18:39
von lunar
Nun, bei zentralen VCS wie SVN sind die Revisionsnummern noch aussagekräftig, da sie zentral verwaltet werden, aber bei verteilten VCS würden sie gar nichts mehr aussagen!

Nehmen wir z.B. an, jemand brancht ein verteiltes Repo, und implementiert viele kleine Änderungen in vielen kleinen Patches. Das treibt die Revisionsnummern nach oben. Auf der anderen Seite setzt sich der andere aber einen Monat lang hin, entwickelt zu Hause eine komplette Neuimplementierung mit ein paar coolen neuen Features und pflegt diese Änderungen mit nur wenigen, großen Patches ein. Die Revisionsnummer steigt nur wenig, trotzdem ist dieser Zweig aktueller als der andere.

Oder Beispiel Kernelentwicklung: Da ist die Entwicklung zerfasert in viele individuelle Trees und Branches, so dass man unter Umständen eine Kernel aus einem Entwickler-Tree installieren kann, der zwar brandneue Ext4-Features hat, aber sogar noch ohne Tickless Timer läuft. In diesem Fall würde die Revisionsnummer überhaupt nichts mehr aussagen, da verschiedene Codeteile von verschiedenster Aktualität sind.

Deswegen verzichtet git gleich auf eine fortlaufende Zählung, und gibt Commits lieber eindeutige, auf Hashes basierte Namen.

Imho sollte man die Revisionsnummer für nichts heranziehen, und auch am besten nicht in die Quellen schreiben.

Verfasst: Mittwoch 16. Januar 2008, 17:46
von birkenfeld
svn-keywords funktionieren nur auf geänderten dateien
Wie meinst du das?

Verfasst: Mittwoch 16. Januar 2008, 21:56
von veers
birkenfeld hat geschrieben:
svn-keywords funktionieren nur auf geänderten dateien
Wie meinst du das?
Das die ID in einer Datei jeweils die der letzten Änderung an dieser Datei ist und nicht die des Checkouts ;)

Und Lunar, die Revisionsnummer im Falle eines zentralen Systemes respektive der Hash bei dezentralen ist vor allem dann wichtig wenn du wissen willst welchen Code ein bestimmtes Build enthält. Im Falle der SVN Revision ist es aber noch wichtig heraus finden zu können aus welchem Branch der Code stammt - diese Information ist in der Revision nicht enthalten.