Welche Namenskonventionen verwenden Sie für SVN-Zweige und -Tags?

Question

Unser Unternehmen erstellt eine Namenskonvention für SVN-Zweige und -Tags, und ich bin nicht zufrieden mit der Idee, nur Datums- oder Build-Nummer auf Zweigen/Tag-Namen zu verwenden.

Ich denke, wir brauchen Namen das bringt eine größere Definition darüber, was dieser Weg darstellt, welche Anstrengung unternommen wird, usw.

Was denken Sie/verwenden?

Answer 1

Alle unsere Entwickleraufgaben gehen in ein Fehlerverfolgungssystem. Dieses Fehlerverfolgungssystem weist mit jeder Aufgabe IDs auf.

Also für den Zweig Namen jeder Aufgabe, verwenden wir:

ticketId_TicketSubject

Wenn ein Zweig mehrere ticketIds enthält kombinieren wir sie nur in den Zweigname:

ticketId1_ticketId2_Description

Auf diese Weise können Sie, wenn Sie in einem Ticket sind und wissen möchten, welchen Zweig Sie erstellen möchten, einfach nachschlagen. Ebenso, wenn Sie das Ticket mit Ihrer Zweigstelle finden möchten, können Sie es auch leicht finden.

Für Tags versehen wir sie mit der Versionsnummer selbst.

Wie für den Standort jeder Niederlassung. Wir haben eine Top-Level-Hierarchie wie folgt aus:

/branches

/tags

/trunk

dann alle unsere Produkte/Projekte in ihren eigenen Unterordner unter jedem dieser gehen.

/trunk/project1/

/branches/project1/TicketId_Description

Answer 2

Für einen Funktionszweig, Namen, nachdem er, was getan wird. Zum Beispiel habe ich unseren ORM von LINQ nach SQL nach NHibernate verschoben und einen Zweig namens "NHibernate" erstellt. Nachdem Sie die Verzweigung abgeschlossen und wieder in die Verbindung eingefügt haben, können Sie die Verzweigung löschen, um Namenskonflikte zukünftig zu speichern. Wenn Sie wirklich die Verzweigung abrufen müssen, die Sie können, müssen Sie nur zurück in den Verlauf eintauchen und ihn wiederherstellen.

Wenn Sie Story/Zitat/Job-Nummern, die für eine Branche relevant sind, würde ich es an den Namen der Niederlassung z. "NHibernate_429", sodass Sie es leicht mit Ihrem Tracking-System verknüpfen können. Ich würde jedoch immer zuerst mit den Engländern sprechen, denn das ist es, woran die Leute sich in der Entwicklungsphase orientieren.

Für Dinge wie Tags ist es schwer zu sagen, was Sie tun möchten, da es darauf ankommt, was Sie markieren. Wenn Sie Releases markieren, würde ich "Release X.X.X.X "oder etwas einfaches wie das. Sie interessieren sich wirklich nicht, was das Datum oder die Aufbaunummer war, wenn Sie zurück nach einer spezifischen Freigabe als ein Beispiel schauen.

Answer 3

, was wir benutzen (meistens folgend der anerkannten Konvention) :

projectName 
| 
--trunk 
| 
--tags 
| 
--branches 

Unter Stamm haben wir den Hauptstamm

Unter Tags wir jede Veröffentlichung (intern, Testmitteilungen und Kundenmitteilungen) markieren Es verwenden, um die Versionsnummer als Tag-Namen wir nur

...

Unter Filialen haben wir o ne Verzweigung für jede von uns veröffentlichte Hauptversion (in unserem Fall das Ergebnis einer XP-Iteration). Diese werden wie die Hauptversion benannt ("v5.03", "v6.04"). Zusätzlich haben wir interne Zweige für größere Änderungen oder spezielle Versionen. Die Benennung ist frei, und der Name soll den Leuten sagen, was der Zweig darstellt. Beispiele wären "workaround_customerA", "module_x_reorg" etc.

Answer 4

Wir geben unseren Filialen eine ".X" Version, wo die Tags eine Nummer haben.

Zum Beispiel würde der Zweig sein Foo-1.2.3.X, und die Tags wäre Foo-1.2.3.1, Foo-1.2.3.2 usw.

Wir haben auch einen speziellen Tag, Foo -1.2.3.0, die ausgeführt wird, sobald die Verzweigung aus dem Stamm erstellt wird, bevor Änderungen vorgenommen werden. Das ist so, dass wir Verzweigungen und Tags zu jeder Zeit in den Anfangszustand bringen können (da in ein paar Tagen der Stamm wahrscheinlich anders ist). Diese Vorgehensweise hat die Zusammenführung etwas vereinfacht und macht es leichter herauszufinden, welcher Code sich in der Branche geändert hat.

Answer 5

Ich setze immer die Tags (und normalerweise auch Zweige) mit dem Datum im JJJJMMTT-Format, gefolgt von einer Beschreibung des Zwecks des Tags oder der Verzweigung.

z.B. 20090326_Release_v6.5 oder 20090326_Post_Production_Update

Dies ist unter dem Standardstamm/tags/branches Hierarchie natürlich.

Das Datumspräfix stellt sicher, dass alle Tags oder Zweige in der Erstellungsreihenfolge angezeigt werden, was viel nützlicher ist, als nur nach Beschreibung sortiert zu werden, wenn Sie durch einen großen Ordner mit Tags scannen. Sie sehen die Zeitachse, wann und warum sie erstellt wurden (wie Mini-Log-Nachrichten).

Answer 6

Nun, Verzweigung ist ziemlich offen, da es verschiedene Arten von Verzweigungen gibt, deren Benennung sehr unterschiedlich sein kann.

Es lohnt sich, sich daran zu erinnern, welche Quellensteuerung Ihnen zur Verfügung steht. Tag-Namen sind nicht nur "v1.4", sondern "/CashCowProject/tags/v1.4". Das Benennen eines Tags "/CashCowProject/tags/CashCowProject-v1.4" ist etwas überflüssig, was wäre es sonst noch?

Die Versionskontrolle gibt Ihnen auch vollen Zugriff auf Datum und Uhrzeit, zu der die Tags erstellt wurden. Revisionssteuerung gibt Ihnen auch Commit-Nachrichten, die Sie verwenden sollten, insbesondere die erste Zeile.

all diese Informationen gegeben, dann ist es nicht schwer, zusammen, um eine einfache Ansicht ziehen Sie alle Informationen, die Sie benötigen, die aus konsistenten und geeigneten Quellen, wie zum Beispiel:

CashCowProject 
    v1.4 - 26 March 2009  : With Added whizzbang (more) 
    v1.3 - 13 February 2009 : Best graphics!  (more) 
    v1.2 - 01 January 2009 : Upgraded security (more) 

Das einzige, was der Tag-Name ist wirklich nützlich, denn hier ist die Versionsnummer.Wenn Sie versuchen, alle Informationen in einen Tag-Namen zu bringen, ist es ein wenig wortreich und ich wette, es wird nicht so gut aussehen.

Answer 7

Besser:

<projectname>_<Year>_<minor>_00 

wie:

XYZ_14_01_00