Hallo, ich habe eine allgemeine Frage zur Versionierung von Software, bzw. zur Vorgehensweise. Ich setzte z.B. Tortoise SVN ein um die Software zu versionienieren, jedoch ergeben sich hierbei zwei Probleme. Zum einen wird die SVN-Revision erst zugewiesen wenn man den Code committet und zum Zweiten wird die Revision auch hoch gezählt, wenn man aus dem Trunk z.B. einen Tag erstellt. Meine jetztige Vorgehensweise ist etwas umständlich. Bevor ich den Code committe sehe ich im Repro-Browser nach was die letzte Revision ist. Dann zähle ich die Revision um eins hoch, trage diese Nummer in meinem Sourcecode ein, compiliere und committe anschließend den Code. Somit ist die Revision in SVN und meinem Code identisch. Ich würde lieber die Softwareversion unabhängig von der SVN-Revision führen. Das würde aber bedeuten das man eine Cross-Referenz-Liste führt aus der der Zusammenhang von Softwareversion und SVN-Revision hervorgeht. Gibt es dafür Tools? Wie macht ihr das?
Michael Stahl schrieb: > Zum einen wird die SVN-Revision erst zugewiesen wenn man den Code > committet Das ist bei solchen Systemen normal. > und zum Zweiten wird die Revision auch hoch gezählt, wenn man > aus dem Trunk z.B. einen Tag erstellt. Das war eine Grundsatzentscheidung der SVN-Entwickler. Die haben gesehen, dass auch bei anderen Repositories die internen Code-Revisionsnummern und das was man extern als Versionsnummer auf das Produkt schreibt nur wenig miteinander zu tun haben. > Meine jetztige Vorgehensweise ist etwas umständlich. Bevor ich den Code > committe sehe ich im Repro-Browser nach was die letzte Revision ist. > Dann zähle ich die Revision um eins hoch, trage diese Nummer in meinem > Sourcecode ein, compiliere und committe anschließend den Code. Somit ist > die Revision in SVN und meinem Code identisch. Das automatische oder manuelle Eintragen von Versionsnummern in Dateien ist eigentlich aus der Mode gekommen. Wenn du es noch haben willst, Subversion kann das: http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html Aber, zentrales Element in einer modernen Entwicklung ist immer das Repository, nicht irgendwo frei rumfliegende Dateien. Frei rumfliegender Code zählt nicht, mit dem arbeitet man nicht. Man holt sich Code immer aus dem Repository um ihn zu verwenden (editieren, bauen, etc.). > Ich würde lieber die Softwareversion unabhängig von der SVN-Revision > führen. Das würde aber bedeuten das man eine Cross-Referenz-Liste führt > aus der der Zusammenhang von Softwareversion und SVN-Revision > hervorgeht. Ja, das ist normal- auch bei anderen Repositories. Die Versionsnummer die man extern verwendet ist oft ein Marketing-Tool und hat mit internen Code-Revisionen nur wenig zu tun. Die Handhabung der MArketing-Versionsnummer beschreibt man in einem separaten Release-Prozess. Eine Liste, was genau in eine Release eingegangen ist, nennt man BOM (Bill of Material) oder Manifest. So eine Liste verwaltet man in der Tat separat als teil des Release-Prozesses. > Gibt es dafür Tools? Wie macht ihr das? Es mag Tools geben. Aber ein paar Zeilen Scripting um http://svnbook.red-bean.com/de/1.5/svn.ref.svnversion.re.html und andere Tools herum tun es auch.
Michael Stahl schrieb: > Meine jetztige Vorgehensweise ist etwas umständlich. Bevor ich den Code > committe sehe ich im Repro-Browser nach was die letzte Revision ist. > Dann zähle ich die Revision um eins hoch, trage diese Nummer in meinem > Sourcecode ein, compiliere und committe anschließend den Code. Somit ist > die Revision in SVN und meinem Code identisch. Warum tust du das und was bringt es dir?
Die Softwareversion ist in meinem Fall die SVN-Revision. Diese kann auch abgefragt werden. Wenn also ein Kunde mir die "Softwareversion" nennt, weiß ich direkt welche Revision er hat und ich kann in den Sourcen nach sehen, bzw. kann mit dieser Software testen. Besser finde ich es wie es Jay (Gast) beschrieben hat. Das das Software Repository unabhängig läuft und in einem separaten Tool zu der Version dann die Revisionen notiert werden.
ich nutze das ganze unter Windows und habe dazu eine kleine batch:
1 | @echo %CD%|findstr /i \tags\ > nul || @goto c1 |
2 | @rem ----- TAG ----- |
3 | @set version=%CD% |
4 | @set version1=%version:~-5,1% |
5 | @set version2=%version:~-3,1% |
6 | @set version3=%version:~-1,1% |
7 | @goto create |
8 | |
9 | :c1 |
10 | @rem ---- TRUNK ---- |
11 | @set version1=0 |
12 | @set version2=0 |
13 | @set version3=0 |
14 | |
15 | :create |
16 | @echo /* %verb%>version.h |
17 | .... |
Hier wird festfestellt, ob ich mich im trunk oder tags zweig befinde. je nachdem ist die Version 0.0.0 oder 1.2.3. Es wird eine "version.h" erstellt, die ich im projekt includiere. nachteil, die nummer dürfen nur einstellig sein. für kleine private zwecke ist das ausreichend.
Michael Stahl schrieb: > Ich würde lieber die Softwareversion unabhängig von der SVN-Revision > führen. Dafür gibt es den TAG. Man (checkt aus) trägt (in Resourcen/dem Code) die Versionsnummer ein, compiliert (erfolgreich) und testet (erfolgreich) und checkt mit dieser Versionsnummer als TAG neu ein, inklusive Kompilate. Das kann der Build vollautomatisch machen. War Kompilierung oder Test nicht erfolgreich, hat man keine Versionsnummer verbraten, man hat immer Produkte zum Ausliefern in lückenloser aufsteigender Versionsnummerierung.
Hallo MaWin, wenn Du die Version als TAG eincheckst, wird doch auch die Revision hoch gezählt. Ist also nicht gleich der im Code, oder hab ich Dich falsch verstanden?
Die Revision wird auch beim erstellen eines TAGs hochgezählt. Aber wenn der Kunde einen Fehler in Version 1.2.3 meldet dann lädst du eben nochmal TAG 1.2.3 und kannst dort den Fehler nachvollziehen. Welcher Revision des letztendlich entspricht kann dir dann egal sein.
Schau dir mal das Programm SubWCRev an. http://tortoisesvn.net/docs/nightly/TortoiseSVN_de/tsvn-subwcrev.html Damit bauen wir unsere VersionNr auf.
1 | #define VERSION_NR_STR "a.b.c.$WCREV$.$WCMODS?1:0$"
|
a + b + c sind von uns händisch eingetragene Nr. die mit der Projekt-Nr und den Milestones des SW-Projektes übereinstimmen müssen. Wenn der Code modifiziert ist wird die letzte Stelle eine 'Eins' ansonsten eine 'Null'! Hausregel bei uns ist: keine SW mit '.1' am Ende verlasst das Gebäude!!!! aufgerufen wird das bei uns als Pre-Build Step: SubWCRev . VersionNrStr.tmpl VersionNrStr.h -fe hier noch einige Beispiele: http://tortoisesvn.net/docs/nightly/TortoiseSVN_de/tsvn-subwcrev-example.html
Michael Stahl schrieb: > Die Softwareversion ist in meinem Fall die SVN-Revision. Kannst du so machen, aber dann ist eine andere Vorgehensweise sinnvoller: Die Revision wird nicht ins Repo eingecheckt, sondern beim Auschecken der Quellen, aus welchen die Software schlussendlich erzeugt wird, wird auch SVN-Revision und -Branch abgefragt und in die Software eincompiliert. Dann würde my-software.exe --version z.B. ausgeben "foo version 1.1 SVN branches/test r1234" Die "1.1" könntest du per Hand pflegen falls gewünscht, d.h. hard codiert in Software. Das "branches/test r1234" entsteht erst beim Generieren der Software. Damit kannst du dann besser nachvollziehen, wie deine 1.1 zustande kam — vorsugesetzt die Build-Umgebung ist definiert bzw. auch Teil des Projekts.
Wir machen das bei uns mit den 4 Feldern der Versionsnummer: Major.Sprint.Commit.Build Major wird fest vergeben, Sprint ist die Nummer des aktuellen Acrum-Sprints, Commit halt SVN und Build die Nummer des Builds auf dem Teamcity Buildserver. Das hat den Vorteil, dass es auch mit dem Windows msi Installer conform ist, denn den interessieren nur die ersten 3 Felder.
Wenn man SVN nich kapiert oder kompliziert findet, liegt das nicht am Nutzer. SVN ist einfach nur Mist. h Nimm GIT. Mach es einfach. Alles andere ist eh totes Wissen.
Steffen K. schrieb: > Nimm GIT. Mach es einfach. Alles andere ist eh totes Wissen. Wow, da hat jemand aber ein ganz fundiertes Wissen, dass er uns nicht mitteilen möchte. Anderst kann ich mir diesen Kommentar nicht erklären. Besonders die Aussage: "Nimm GIT. Mach es einfach." höhre ich seeeeehhhhhr selten und wenn, dann von kleingeistern die sonst nichts kennen. Und wenn es dann doch so einfach wäre, hättest du ihm sicher eine Lösung in GIT mit einem Einzeiler präsentieren können, oder etwa nicht?
Steffen K. schrieb: > Wenn man SVN nich kapiert oder kompliziert findet, liegt das nicht am > Nutzer. Doch, denn SVN ist einfach zu verstehen. > Nimm GIT. Das wollte ich eigentlich mal tun, aber hab auch nach lesen der Anleitung nicht kapiert, wie es funktioniert.
Steffen K. schrieb: > Wenn man SVN nich kapiert oder kompliziert findet, liegt das nicht am > Nutzer. SVN ist einfach nur Mist. h Ich komme damit gut zurecht. Liegt das dann an mir? Muß ich mir Sorgen machen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.