Datei vor Subversion Commit ändern

Question

Ich verwende TortoiseSVN für Windows und möchte herausfinden, ob ich eine Art Makro einrichten kann, um eine der Dateien im Projektarchiv bei einer Übertragung zu ändern.

In meinem Subversion-Repository habe ich eine XML-Datei namens "Web.Config". In diesem XML-Dokument gibt es einige Knoten mit dem Tag-Namen "add", die die "Build-Nummer", die "Build-Beschreibung" und das "letzte Build-Datum" unter dem XML-Pfad /Configuration/appSettings darstellen. Diese XML-Datei verwendet das Attribut "key" des Knotens "add", um festzustellen, welche dieser Einstellungen festgelegt werden.

Die oben genannten Knoten werden vor jeder Übergabe von Hand geändert (angeblich, aber ich mache das nicht immer).

Meine Frage ist: Ist es möglich, diese Einstellungen in der Datei zu ändern, wenn ich sie übertrage?

Answer 1

Erwägen Sie die Verwendung von subwcrev.exe, um die Build(Revisions)-Nummer in Ihre web.config zu injizieren nach die Übergabe. Meiner Erfahrung nach wird das normalerweise so gemacht (anstatt es vor dem Commit zu machen) - fügen Sie subwcrev einfach als Build-Schritt, Post-Build-Schritt oder als Teil Ihres "Publishing"-Schrittes hinzu.

Wie ich bereits in einem Kommentar weiter oben angemerkt habe, bin ich mir nicht sicher, ob es eine gute Idee ist, einen Pre-Commit-Hook zu verwenden, da dies bedeuten würde, dass Ihre lokalen Dateien in dem Moment, in dem Sie sie übertragen, sofort veraltet sind.

Answer 2

Sie können wahrscheinlich ein Pre-Commit-Hook-Skript verwenden. Mit Pre-Commit-Hooks können Sie Skripte ausführen, unmittelbar bevor der Server Ihre Änderungen festschreibt. Ein guter Artikel über das Einrichten eines Pre-Commit-Hook-Skripts ist aquí

Answer 3

Vielleicht mit svn pre-commit hooks?

Die andere Möglichkeit (die ich bevorzugen und verwenden würde) besteht darin, diese Daten während der Erstellung in Ihrer Web-Assembly zu platzieren und sie dann programmatisch in Ihrem Code zu lesen. Wenn Sie .NET verwenden, das ist :)

1. Fügen Sie einen Schritt zu Ihrem Build hinzu, um eine gemeinsame AssemblyInfo.cs zu erzeugen. (siehe [ [http://blog.darrenstokes.com/2007/12/17/ease-versioning-multiple-assemblies-by-splitting-up-assemblyinfo/\]](http://blog.darrenstokes.com/2007/12/17/ease-versioning-multiple-assemblies-by-splitting-up-assemblyinfo/]) ) 1
2. "Fügen Sie diese Datei als Link zu jedem Ihrer Projekte hinzu

3. Wenn Sie diese Informationen benötigen, können Sie sie z. B. über Reflection abrufen:

   System.Diagnostics.FileVersionInfo version = System.Diagnostics.FileVersionInfo.GetVersionInfo
   (System.Reflection.Assembly.GetExecutingAssembly ().Location);

   Console.Out.WriteLine ("MyApplication v{0} by Me", version.FileVersion);

Answer 4

Vielleicht können Sie ein anderes System finden, bei dem Sie die Dateien nicht auf diese Weise ändern müssen.

Außerdem vermute ich, dass Sie Nicht-Quellcode, der nicht von Abhängigkeiten abhängt, in die Quellcodekontrolle aufgenommen haben. Ich würde nur den Quellcode für Ihre Projekte sowie die Assemblies von Drittanbietern, auf die Ihre Projekte verweisen, in die Versionskontrolle aufnehmen. Ich würde die Projekte ignorieren. \bin y \obj Verzeichnisse.

Jeder sollte in der Lage sein, die neueste (oder eigentlich jede beliebige) Version aus der Versionskontrolle auszuchecken, externe Faktoren für seine Umgebung einzurichten (eine Datenbank zu erstellen, Berechtigungen festzulegen usw.), die Build-Skripte des Projekts auszuführen und eine voll funktionsfähige Anwendung zu haben.

Aber die neuesten .dll's oder .msi's direkt in der Versionskontrolle zu halten ist nicht notwendig, um ein voll funktionsfähiges Projekt zu haben und ist vielleicht keine so gute Idee.