Ich habe eine asp.net/C# App, die Subversion für die Quellcodeverwaltung verwendet.
Meine App erhöht automatisch AssembleVersion und AssemblyFileVersion für jeden Build, der wie ein Charm funktioniert, und zeigt die Build-Nummer in der Verwaltungsseite der Site an.
Wenn wir die Bereitstellung durchführen, behalten wir den Überblick über AssembleVersion und AssemblyFileVersion. Wenn jedoch ein Problem auftritt und wir zu einer bestimmten Version zurückkehren müssen, haben wir keine Idee, welche Revision in subversion behandelt werden soll.
Ich habe wenige Ideen:
Jede Hilfe und Vorschläge werden geschätzt
Aktualisiert: Option "1" ist eigentlich eine dumme Idee, denn das bedeutet, dass jedes Mal, wenn ich es erstelle, alle Dateien als aktualisiert markiert werden und wenn ich festlege, wird jede einzelne Datei aktualisiert
Wenn ich baue, lege ich diese Build-Nummer überall hin.
Das Einzige, in das ich es nicht hineinziehe, ist mein Kaffee, den ich schwarz nehme . p>
All dies ermöglicht einem Betreuer auf einen Blick zu erkennen, woher der Code stammt, was er gerade sieht, ob er eine Webseite anzeigt oder die Eigenschaften einer der erstellten Baugruppen im Explorer oder was auch immer betrachtet .
Tags sind nicht wirklich nützlich, wenn Sie häufig bauen. Vielleicht finden Sie eine Möglichkeit, Assembly-Version auf der Grundlage der Svn-Revision zu aktualisieren? Geben Sie auch den Zweignamen an, da sie die Revisionen gemeinsam nutzen.
Und Sie sollten in der Lage sein, die Assembly-Version in Ihren ASP.NET-Seiten zu extrahieren und sie programmatisch in einer Fußzeile oder ähnlichem zu drucken.
Sie könnten den Subversion-Stamm mit AssembleVersion oder AssemblyFileVersion taggen, je nachdem, was am sinnvollsten ist.
Sie können die Subversion-Revisionsnummer genauso verfolgen, wie Sie die AssembleVersion- und AssemblyFileVersion bei der Bereitstellung verfolgen.
Wenden Sie ein Tag auf Ihren Quellbaum an, nachdem Sie die AssemblyVersion und AssemblyFileVersion aktualisiert haben.
Sie könnten "zur Veröffentlichung" verzweigen. Bevor Sie einen Release-Build erstellen, können Sie den Stammzweig verzweigen und dann einen Tag für den neuen Zweig mit der Release-Versionsnummer erstellen.
%Vor%Damit können Sie alle einzelnen Releases in SVN verfolgen. Es würde Ihnen auch erlauben, isolierte Fehlerbehebungen in Release-Zweigen zu machen, die als Patches veröffentlicht werden könnten. Der Bugfix könnte dann wieder in den Trunk integriert werden.
%Vor%Tags / Zweige sind definitiv der empfohlene Ansatz hier.
Sie können (oder zusätzlich) die svn-Revisionsnummer in Ihre AssemblyInfo einfügen. Ein Ansatz besteht darin, die AssemblyInfo-Task aus dem Msbuildtasks-Projekt in Ссылка
zu verwendenWeitere Informationen erhalten Sie unter msbuild svn revision assemblyinfo
Sie könnten dann ohne Tags / Zweige auskommen, da Sie immer eine bestimmte Revision auschecken und / oder eine Verzweigung aus einer bestimmten Revision erstellen können.
Eine andere Möglichkeit ist, die letzte geänderte Version als Ihre Build-Nummer zu verwenden. Dies bedeutet jedes Mal, wenn Sie ein Auto-Tag erstellen. Es ist einfach mit Hudson / Jenkins, da Sie eine Umgebungsvariable SVN_REVISION haben. Das Problem ist, dass die Revisionsnummer sehr groß wird und Diskussionen im Flur über 1.0.0.20456 vs 1.0.0.20489 sind ein Bissen.