•  05-09-2019
  •  | 
  •  

Frage

Wenn ich im SVN aussehen log ich wünschte wirklich, ich Markierungen sehen konnte, die mir sagen, wenn Releases fertig waren. Ich habe dies in anderen Versionskontrollsystemen gesehen wie PVCS und Perforce .

Kann man das in SVN zu tun? Ich habe ein wenig Forschung getan und bisher sieht es aus wie diese Art der Sache nicht unterstützt wird.

Bearbeiten

Wir wollen nicht haben, unsere Quelle in einem anderen Ordner für die jeweilige Version zu kopieren. Dies führt zu einer enormen Menge unnötiger Doppel von Dateien auf der Entwickler-Maschine und gibt uns nur eine Aufzeichnung der Revisionsnummer von jedem Release. Ich kann tun, dass ein Textdokument mit!

EDIT2

Mein Ziel ist es, eine einheitliche Sicht zu haben, die mir eine Chronologie meiner Veröffentlichungen zeigt, zwischen denen ich alle Codeänderungen sehen, die zwischen jedem Release statt. Dies macht es dann leichter Release Notes zu erstellen.

War es hilfreich?

Lösung

Richard, Tags sind sehr nah, aber ich frage mich, ob das, was Sie vielleicht nicht ein spezieller Release-Zweig sein müssen.

Dazu einen Zweig vom Stamm macht früh genannt etwas wie ‚Release‘. arbeitet dann am Stamm als normal, wenn Sie für eine Veröffentlichung bereit sind, zusammenführen, um die Änderungen vom Stamm in ‚Release‘. Dies ist die einzige Möglichkeit, dass Sie Release ändern sollten.

Sie können dann von der Freigabe markieren, wenn Sie wollen, nicht 100% notwendig.

Aber was das wird Sie geben, ist ein Zweig, der eine Teilmenge des Rumpfes des Revisionen in ihm hat. Finden Sie Ihre Veröffentlichungsdaten mit: 

svn log --stop-on-copy svn://server/project/branches/release

Dies wird Ihnen eine Liste der Freigabedaten (mit den Revisionen). Um zu sehen, was in jeder Version ist zu tun: 

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

Beachten Sie auch, dass durch diese Art und Weise arbeiten, werden Sie auf eine streng sequentielle Freigabe von alles in Stamm nicht darauf beschränkt - Sie Kirsche Revisionen auswählen können, ohne Revisionen wenn Sie wollen sie nicht loslassen nur noch, aber immer noch nachfolgende einschließlich Revisionen.

Andere Tipps

Nicht als solche. Die akzeptierte Art und Weise veröffentlicht in SVN zu tun ist, ein „tags“ Verzeichnis haben, wo Ihre Freilassung Quelle für jede bestimmte Version kopiert. Zum Beispiel /tags/release-0.11 ... Es ist alles, was man nicht von Messing mit dem tags Verzeichnis durch Unfall zu verhindern, aus dem Kasten heraus, aber einige Leute gerne einrichten Haken pre-commit, um ein versehentliches Commits zu verhindern Tags freigeben.

Hier ist ein beschreiben anständige Artikel rel="noreferrer"> ein Freigabeprozess in SVN.

  

Mein Ziel ist es, eine einheitliche Sicht zu haben, dass   zeigt mir eine Chronologie meiner Veröffentlichungen,   zwischen denen ich alle die sehen   Code-Änderungen, die sich zwischen   jede Veröffentlichung.

Haben Sie die Schildkröte SVN Revision Graph untersucht? Wenn Sie jede Veröffentlichung markieren (die, wie andere darauf hingewiesen haben, ist nicht mit dem Kopieren von Dateien, entweder auf dem Server oder die Workstation), dann können Sie alle Änderungen in chronologischer Reihenfolge, mit den Tags anzeigt tatsächlichen Releases. Sie können durch hilighting die beiden Revisionen zwischen den Veröffentlichungen und / oder Kofferraum diff Sie interessiert sind und diff Auswahl aus dem Kontextmenü.

Kopieren der Stamm auf einen Tags Pfad im SVN-Repository ist der Weg, dies zu erreichen. Es ist eine SVN-Kopie, so nicht mit Duplikaten von Dateien auf dem SVN-Repository-Server beenden. Sie haben nur doppelte Dateien lokal, wenn Sie einen SVN anderen Weg als den Stamm zur Kasse gewählt haben. Commits auf diesen Arbeitskopien dann gehen Sie zurück zum SVN-Weg, den sie überprüft wurden aus.

Dies ist im Wesentlichen eine bestimmte herkömmliche Implementierung in svn der Verzweigung. Werfen Sie einen Blick auf die Online svn Buch für weitere Details.

würde die Markierung die schriftliche begehen seine Meldung, wenn ein Tag für die Freigabe gemacht wird (a svn Kopie an den / Tags). Zumindest das ist die am häufigsten verwendete Methode verwendet wird.

Während Subversion nicht Release-Management zur Verfügung stellt an und für sich, Versionskontrolle Werkzeuge sind nicht in der Regel mit dieser Tätigkeit beauftragt. Was Sie suchen ist eine Aktivität / Ausgabe / Change-Management-Tool, das mit Subversion in Wechselwirkung treten kann.

Zu diesem Zweck wir Jira an meinem Arbeitsplatz verwenden und wir verknüpfen es mit Subversion. Jira bietet einen Fahrplan und Änderungshistorie, die Probleme in den einzelnen Versionen enthält. Jede dieser Fragen hat Links zu den Änderungen in Quellcodeverwaltung. So können Sie mit freigegebenen Versionen Änderungen im Quellcode verknüpfen.

Ich denke, es ist in der Regel besser diese beiden Werkzeuge getrennt zu halten. Obwohl Perforce insbesondere versucht, die beiden zusammen zu binden, tun sie dies nur einfach. Es gibt einige Dinge, wie Benutzer von Änderungen an Fragen per E-Mail, das Hinzufügen von Kommentaren zu Fragen, das Hinzufügen Anhänge zu Themen, die in einem speziellen Stück Software wie Jira viel besser fertig sind. Auf der anderen Seite Jira nicht sehr gut Versionierung ist, Zusammenführen und Verzweigen Quelle ..., die besser in einem speziellen Stück Software wie Subversion behandelt wird.

Für die vollständige Offenlegung gibt es andere Werkzeuge als Jira wie Bugzilla, Trac, IBM Rational Jazz, etc., die die gleiche Sache mit Subversion tun können, die Jira tut allerdings mit unterschiedlicher Funktionalität.

Werfen Sie einen Blick auf die SVN Buches Themen:

Schlagwörter und Surfen im Repository

Stichworte und Zweige „copy-on-write“, was bedeutet, dass es keine zusätzlichen Kopien im Repository. Im Allgemeinen ein einzelner Entwickler nicht braucht eine lokale Kopie haben, wenn er es für einen Grund benötigt (I.E. auf einem Zweig der Entwicklung).

Wenn Sie jede Veröffentlichung markieren, dann können Sie die Tags sehen durch das Repository durchsuchen. Die obigen Links sprechen direkt über die Kommandozeilen-Tools, aber es gibt auch GUI-Tools wie TortoiseSVN unter Windows. Sie können die Geschichte bekommen, tun Vergleiche, etc.

Um die Änderungen in einer Pressemitteilung zu sehen, würden Sie zeigen nur ein Protokoll des Stammes aus der Revision der Tags Sie zurück Revision des auf den vorherigen Tages wollen +1. Es klingt wie zusätzliche Arbeit, aber es ist ziemlich einfach, sobald man sich daran gewöhnen.

Mit unseren Build-Tool verpflichten wir auch eine Datei mit einiger Versionsnummer Informationen zurück an der Stamm zurück, und der Kommentar hat die Versionsnummer des Build. Wenn Ihr Hauptcode im Kofferraum ist, kann dies auch als Marker arbeitet für das, was in einem Build ist (Blick zwischen der Version verpflichtet).

1 für die Verwendung der Nachricht begehen.

Für ein Projekt habe ich einen SVN Benutzer namens Build. Die Build-Maschine verwendet, um dieses Login für SVN. Jedes Mal, wenn der Build-Maschine / Prozess einen Build tat es auch aktualisiert, um eine Datei und die SVN Commit-Nachricht die Version / andere Kennung für den Build war.

Dann haben wir auch einen Tag für diese zu bauen. Auf diese Weise in den Kofferraum wir das sehen konnte, baut wann / wo sie mit anderen Änderungen durchsetzt sind.

Also mein Vorschlag (einfachste Weg, es zu tun) ist eine weitere Dateien namens Build (oder etwas anderes wollen Sie) zu erstellen und zu diesem anhängen oder ändern Sie es einfach in Ihrem Build-Skript / Prozess, und es dann in / commit prüfen, es mit dem Namen der Release-Version als die Nachricht begehen. Einfach. Es wird dann in Ihrer Geschichte Abfragen angezeigt.

Außerdem, wenn Sie wissen, welche Änderungen Sie vergleichen Sie können eine SVN diff tun, und Sie werden sehen, welche Dateien geändert haben und wie zwischen den beiden Versionen.

Nicht sicher über Ihre Gesamt Setup aber jemand erwähnt TortoiseSVN. Das ist definitiv ein guter Anfang. Ich benutze Eclipse-persönlich mit dem subclipse Plug-in und es erlaubt mir diffs in einer grafischen Umgebung zwischen Versionen auszuführen. Solange Sie Ihr Projekt haben Ihre jede Änderung auf andere Revision vergleichen können und als solche Sie nicht alle Arten von Dateiduplikaten haben müssen.

Auch wir in der Regel drei Verzeichnisse in jedem Repository einzurichten. Äste, Stamm und Schlagwörter. Als jemand erwähnt, sind die Tags speziell zur Identifizierung einer Freisetzung verwendet.

Ich begegne das gleiche Problem und die Art, wie ich versucht habe es für mein Unternehmen zu beheben, ist ein ‚Release‘ -Ordner im Kofferraum zu haben, dieser Ordner enthält nur die eigentliche ausführbare Datei oder was muss ein Teil des Einsatzes sein.

ich einen neuen Ordner erstellen für jede Version beginnend mit ‚1.0.0.0‘ in ‚release‘ Ordnern und markieren auch den Code mit dem gleichen Release Ordnernamen d.h 1.0.0.0 im Fall.

Ich bin nicht sicher, ob es der richtige Weg ist, es zu tun, aber es löst mein Problem ausführbar, um herauszufinden, dass ich bereitgestellt haben.

Wenn Sie die normale svn Konvention von „tags / branches / trunk“ an der Wurzel Ihrer Repository folgen, würden die Entwickler der Regel wollen nicht das gesamte Repository auschecken, nur aus dem Kofferraum nach unten.

würde Ich mag einen anderen Ansatz bieten, die Ihr angegebenes Problem lösen helfen sollen: Release Notes Erstellen und Anzeigen von Code Unterschieden zwischen den Versionen.

Wir verwenden ein Programm namens SubWCRev, die mit Tortoise SVN kommt. Wir haben ein Post-Build-Ereignis, das die SVN-Revisionsnummer und steckt sie in eine Datei packt - im Fall von Websites, die wir diese version.html genannt in einer Datei speichern,. Dann wird bei jedem Zeitpunkt Sie Ihre Freilassung binden können (ob das das releas ist derzeit in QA, Prod, oder jeder anderen Umgebung) auf die genaue Versionsnummer in SVN. Nicht mehr Tagging, nicht mehr fragen, was in einer Version enthalten ist, nicht mehr abhör Entwickler eine Version Datei zu aktualisieren.

Um zu bestimmen, was in einer Pressemitteilung enthalten ist, können Sie dann ziehen Sie einfach die SVN-Protokolle von Revision X Revision Y und kopieren Sie die Kommentare in ein Dokument und bearbeiten eine ziemlich Release Notes doc zu machen. Das gleiche gilt für die Code-Review oder diffing die Releases; verwenden Sie einfach die Revisionsnummern gebunden an Ihre version.html, properties.cs, readme.txt etc.

Ich würde vorschlagen, auch eine Art von Artefakt-Repository mit halten Ihre aufbaut. Wenn Sie mit der SVN-Revisionsnummer als Ihre Versionsnummer zu wechseln, können Sie immer auf genau diese Revision im SVN gehen zurück, das bedeutet, dass Sie nicht für jeden Release-Tags oder Kopien Ihrer Quelle müssen in SVN rumliegen.

FYI,

SVN Kopie ist nicht schwer zu kopieren, es verbindet nur deshalb wird jeder Raum nicht nehmen andere als geänderte Dateien. Und diese Versionen werden auf jeden Fall Platz in Anspruch nehmen. So eine Kopie zu erstellen für jede Version wird keinen Platz nehmen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top