✔ NetBeans & Tortoise: aktuelle Revisionsnummer in Quelltext einbinden

[Frezl]

@ Akeshihiro:

Danke für deine Antwort. Ich bin bis jetzt noch nicht sehr damit vertraut, wie die Versionierung in der Praxis funktioniert. Alles was ich bis jetzt gebraucht habe, hab ich mir in den letzten 4 Monaten selbst beigebracht. Bis jetzt ist mein "Kunde" auch nur der Betreuer bei meiner Studienarbeit.

Bis jetzt habe ich Versionen nie getaggt, wenn ich sie exportiert habe. Bei der Web-Entwicklung ist das ja immer so ne fließende Sache, man muss nix kompilieren oder irgendwelche Vorbereitungen fürs Exportieren treffen - wenn ich neue Funktionen implementiert habe und diese funktionieren, mache ich nen Export und lad den auf den Server, wo sich's mein Betreuer anschaun kann. Daher wär's interessant, die Revisionsnummer im About-Dialog (also nur in dieser einen Datei) stehen zu haben.

Bei vielen Softwares mit kurzen Entwicklungs- und Updatezyklen steh'n dort immer endlos lange Nummern, sodass ich davon ausgehe, dass das die Release-Nummern sind. Beim Firefox war das früher z. B. der Fall, aber da steht mittlerweile auch nur noch eine Versions-Nummer.

Ich werd mir die Hooks mal anschaun, ich denke auch, dass da die Lösung des Problems liegt.

Hast du mir vll nen Tipp für ein gutes Tutorial, mit dem ich die praktische Anwendung der Versionierung (wenn ich z. B. in einem Team arbeite) lernen kann?

Viele Grüße,
Frezl

 

[Akeshihiro]

Wie ein Version beim wohl größten Teil der Softwarewelt vergeben wird, wird in diesem Wikipedia-Artikel sehr gut erklärt. Gleichzeitig wird auch erwähnt, dass es noch andere Wege gibt (z.B. aus Marketinggründen), man muss sich nicht dran halten.

Wenn eine neue Version rauskommt, dann sollte man dafür auch ein Tag anlegen. Der Grund ist ganz einfach. Das fertige Build ist eigentlich vollkommen uninteressant. Das wird ausgelifert/deployt und damit hat sich das dann erledigt. Bei den meisten Projekten werden diese Builds zwar archiviert, damit man auch auf ältere Versionen zugreifen kann, aber für einen Entwickler ist viel interessanter, auf welchen Sourcecodes die Version X basiert. Man kann jetzt im SVN oder auch in einem anderen Versionskontrollsystem nach einem Kommentar suchen und schauen, welche Revision das war (sofern man so schlau war und einen solchen Kommentar hinterlassen hat). Man kann aber auch bei dem fertigen Build nach der Revisionsnummer schauen (wie du das machen willst) und so an die richtige Stelle gelangen. Aber wenn das Build nicht mehr vorhanden ist, was dann? Dann ist es gut, wenn die Version getagt wurde.

Bei SVN wird eine Struktur empfohlen, bei der man für das Projekt drei Unterordner hat, in denen sich das Projektleben abspielt: trunk, tags und branches.
Damit sieht das Projekt dann so aus:

- Projektordner
+- trunk
+- tags
+- branches

Die eigentliche Entwicklung findet in trunk statt. Wenn man eine neue Version rausbringt, dann sollte man dafür auch im Ordner tags eine Kopie von trunk ablegen, natürlich mit einem sinnvollen Namen. Dieses tag wird dann nie mehr angefasst, keine nebenläufigen Entwicklungen und gar nix. Das ist ein Abbild des Entwicklungsstandes zu einem ganz bestimmten Zeitpunkt, nämlich als eine Version fertig war.

Beispiel:

- Projektordner
+- branches
+- tags
  +- 0.1.0.123
  +- 0.1.1.134
+- trunk

Da sind jetzt zwei Versionen getagt, einmal eine Version an sich (könnte ne Alpha sein) und dannach ein Patchrelease zu der vorherigen Version. Am Ende habe ich noch die Revisionsnummern drangehängt, damit sofort klar ist, welche Revision dafür verantwortlich ist.

Die Entwicklungsarbeiten finden, wie schon gesagt, in trunk statt oder auch in branches, falls man ein Branch angelegt hat. Branches sind Entwicklungszweige, die parallel entwickelt werden, z.B. neue Features. Aber Tags werden niemals angerührt. Wenn man an einer bereits getagten Version was korrigieren will, dann wird davon ein branch angelegt, die Veränderungen gemacht und wieder getagt (sinnvollerweise dann als Patchrelease). Branching ist aber wieder ne Wissenschaft für sich. Jeder machts anders und irgendwie doch gleich.

Die Vorgehensweise ist auch bei Webentwicklung sinnvoll, denn ob man eine Version tagt oder nicht, hängt nicht davon ab, ob etwas kompiliert werden muss. Das kompilierte Zeug bzw. das was in die Welt rausbefördert wird, ist für den Endbenutzer interessant, für den Entwickler aber eher weniger, denn ihn interessiert viel mehr auf welcher Codebasis die Version aufbaut, die da rausgegangen ist und für die er dann Bugs beseitigen muss. Und auch im Web ist das alles andere als ein in sich übergreifender Fluss. Wenn eine neue Funktionalität dazugekommen ist, dann ist das technisch nicht die selbe Version, sondern eine neue und sollte auch so behandelt werden.

 

[Frezl]

Hey Akeshihiro,

vielen herzlichen Dank für deinen ausführlichen Post! Leider wurde in meinen Vorlesungen die Versionierung zwar als wichtiges Entwickler-Werkzeug vorgestellt, aber nie im Detail erklärt, wie man dabei richtig vorgeht. Deine Erklärung hilft mir da schon ein gutes Stück weiter.
Für dieses Projekt ist es leider zu spät (muss diese Woche meine Ausarbeitung fertig machen und das ganze abgeben), aber in der hoffentlich anstehenden Weiterentwicklung der Software werd ich die Versionierung mal richtig umsetzen.

Viele Grüße,
Frezl