SVN Namenskonvention: repository, Zweige, tags

camelCase? Nein, wir setzen nicht irgendwelche Beschränkungen auf Namen, außer, dass die Räume neigen dazu, entmutigt zu sein. Der Inhalt ist was zählt, nicht die Aufmachung. Solange der name klar definiert ist, was es tut, sind wir glücklich.

Ich denke, die größte Veränderung, die Sie vornehmen können, um alle Ihre Projekte in einer einzigen repo auf der obersten Ebene.

Benutzen wir keine Filialen oder tags Verzeichnisse wie wir haben viele Hunderte von Projekten, die jeweils unterteilt sind versioniert Gruppen (das heißt, wir haben eine Basis-Plattform, die versioniert, und eine Menge von plugins, die live unter jeder Basis-version-Nummer)

zB:

base v1
  +--- moduleA
  +----moduleB
base v2
  +--- moduleA
  +----moduleB

Haben wir uns Gedanken darüber machen, dass ein tag-Zweig unter jedem der Modul-Verzeichnisse, aber wir fast immer mit dem head-version, so dass Ihr nicht ein Problem für uns. Wir regelmäßig Zusammenführen der änderungen von der älteren Basis-version Module zur neuen - z.B. eine änderung moduleA für Basis v1, werden die änderungen zusammengeführt werden, in die base v2 ist moduleA. Wir gehen nicht rückwärts, es sei denn notwendig.

Jedes Modul hat eine release-note mit, die beschreiben, die Versionsnummer und die änderungen. Die log-Kommentar hat einige der Beschreibung und die Versionsnummer. Dies macht es sehr einfach zu vorherigen Versionen, ohne zu viel von tag Zweige, die sind eindeutig benannt. Wenn wir beginnen mit tag-Zweige (wurde vorgeschlagen), dann würden wir machen, einen vollständigen Pfad kopieren in das /tags-Verzeichnis), würden wir immer noch fahren Sie auf einem einzelnen tag-Zweig und legen Sie ein log-Kommentar-Kennzeichnung die release-Nummer, wir haben einfach zu viele Module, die Sie zu verwalten als 1 tag-Ordner pro Zweig. Und Nein, wir nehmen Sie keinesfalls Veränderungen an der historischen Revisionen - wenn ein Kunde braucht eine neue Funktionalität, müssen Sie ein upgrade auf die neueste version (das ist nie ein problem, bis Sie ändern Sie die Basis-Plattform-version)

Benutzen wir keine Niederlassungen entweder, wie wir, sind in der Regel auf die head-version des jeweiligen Moduls, wenn wir das tun, müssen Sie einen Zweig für eine große Reihe von änderungen, werden wir den Zweig auf der Basis-Ebene, so würden wir erstellen eine "base v2 - "performance" - Zweig und ast alles. Dies macht es einfach, um der Gruppe eine Menge von änderungen zusammen, wie klappt es so am besten für uns. Verzweigung der einzelnen Module entstehen würden zu viel Unordnung in den repo - da haben wir ein paar hundert, es wäre leicht den überblick verlieren, ob wir bei Ihnen hatten, Verzweigungen pro Modul.

Ja, wir machen änderungen auf dem Stamm, aber das ist ok mit unserer workflow - Dinge nicht bekommen, verpflichtet sich, bis Sie bereit sind zu gehen. Alle änderungen, die vorgenommen wurden, um die älteren base-Versionen sind nur Bugfixes, und wir haben zu viele Module zu verwalten, Sie in einem full-dev-test-release-Zyklus. Wir reparieren, wenn es beweist, dass ein schlechtes Update, wir fix wieder. Wir ändern manchmal dieser Ansatz für größere Entwicklungen und erstellen Sie einen Zweig auf Zweige Ordner (aus der Wurzel). Der Zweig Pfad neu erstellt, den Pfad zum original-Modul (so seine leicht zu sagen, was es ist, und Zusammenführen von hinten ist so einfach wie das ändern /Zweige /Stamm am Anfang des Pfades).

Die einzige Frage, die wir begegnet bin, in diesem system, wenn wir ein Modul in einem web-app-Projekt (redmine). Wir wollten einen einzigen redmine-Projekt für alle Versionen eines Moduls, aber unsere Anordnung war so, dass es war ein bisschen schwierig, eine Ursache für das repository. Wenn wir könnten, zuordnen eines repo-Pfad mit der jeweiligen version im redmine, dann ist diese Einschränkung würde verschwinden.

Es ist nicht unbedingt das beste für alle, und ich würde empfehlen, mit den Zweigen, aber diese funktioniert für uns (teilweise war es die Art, wie wir gearbeitet haben in einem früheren source-control-system, das war "sicher" und nicht-support-branches/Zusammenführen).

InformationsquelleAutor der Antwort gbjbaanb

Jetzt, wir sind beschäftigt die folgenden standards, die mit SVN...

Normalerweise sind Tags verändert werden. Der Grund, warum Sie tag-ein-release ist, so dass Sie anwenden können, bug-fixes, während die Entwicklung weiterhin auf dem Stamm. Natürlich, den selben bug fixes angewandt werden, um den Kofferraum.

So, wenn Ihr Projekt ist so etwas wie Backyard Baseball für die Youngins, wie geht man damit um?

Sind wir ein Java-shop, so dass alle unsere Projekte sind mit dem Namen gov.bop.Projekt. 🙂 Subversion funktioniert mit jedem Namen.

Wenn du gehst mit dem feature-branch-Paradigma, wie benennst du deine feature branches?

Gehen wir mit der generierten Zahl, die durch unser incident-reporting-system. Es erleichtert die Nachvollziehbarkeit.

Tags scheinen, wie Sie würde profitieren am meisten von den Versionsnummern.

Wir haben festgestellt, dass JJJJMMTT Termine besser arbeiten über einen langen Zeitraum.

InformationsquelleAutor der Antwort Gilbert Le Blanc