Entwicklung einer Versionskontrollstrategie für SVN

9

Außerhalb der Uhr werde ich versuchen, eine Strategie für die Versionskontrolle für mein Unternehmen zu entwickeln. Wir verwenden derzeit SVN, aber es gibt keine Struktur - wir haben im Grunde nur einen Trunk und verpflichten uns nur dazu. Vor kurzem hat der Entwicklungsmanager ein zweites Repository gestartet, das als "Tag" fungiert. Es muss jedoch manuell mit dem "Trunk" zusammengeführt werden, da es nicht Teil desselben Repositorys ist, sondern ein völlig separates. Tatsächlich gibt es nur einen Ordner mit dem Namen "Dev" (es gibt tatsächlich verschiedene "Dev" -Ordner zu unterschiedlichen Daten, aber nur "Dev" ist der Hauptordner) und darunter befindet sich alles andere. alle anderen Projekte. Es ist überhaupt nicht nach Projekten organisiert, es gibt kein Konzept für Zweige / Tag / Stamm oder irgendetwas. Die Person, die es ursprünglich eingerichtet hat (längst vorbei, natürlich) schien überhaupt nicht zu wissen, wie man SVN einrichtet, und seitdem hat sich niemand die Mühe gemacht, zu lernen, wie man Dinge richtig macht, aus Angst, etwas zu zerbrechen. Wir verwenden keinerlei CI (oder leider automatisierte Tests).

Erstens, sollten wir es nach Projekten trennen lassen? Zum Beispiel haben wir: Zwei ASP.NET-Websites (nicht Webanwendungen, Websites), einen Webdienst, einen Bereitstellungsordner für alle Tabellenskripte und gespeicherten Prozeduren, zwei Befehlszeilenclients für externe Projekte, die von der aufgerufen werden Websites und ein freigegebener Ordner mit gemeinsamen Geschäftsobjekten und dergleichen. Sollte jedes dieser Projekte ein eigenes Projekt mit einem Branch / Tag / Trunk-Setup sein oder sollte es so aussehen:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

und haben alle Zweige und alles eine Kopie des gesamten Dev-Ordners? Dieser Ansatz ist möglicherweise leichter zu schlucken, da wir häufig Situationen haben, in denen wir Änderungen an der gemeinsam genutzten Codebibliothek und an mindestens einer (normalerweise beiden) der Websites vornehmen müssen.

Zweitens machen wir regelmäßige Releases ("Pushs" in unserer Sprache) auf unserem Dev-Server und Live-Server. Nach dem, was ich gelesen habe, würde der beste Weg, dies zu handhaben, darin bestehen, dass die gesamte Entwicklung in Trunk / geht, Zweige "temporär" sind und zum Hinzufügen einer neuen Funktion verwendet werden, die sich auf Trunk auswirken könnte, und Tags für Releases vorgesehen sind. Also, wir pushen jeden Monat, sagen wir, und ich arbeite an einem brandneuen Modul. Ich würde Trunk verzweigen und diesen Zweig für meinen Code verwenden, ihn schreiben und testen und was auch immer. Wenn das Modul fertig ist, füge ich es wieder in den Trunk ein (und lösche möglicherweise den Zweig), und wenn wir bereit sind, es bereitzustellen, markieren wir es (sagen wir "May2011"). Wenn wir einen Bugfix haben, nachdem er live geschaltet wurde, wird er im May2011-Tag behoben und in Trunk zusammengeführt (damit Trunk auch den Fix erhält). und dann würde May2011 mit dem Fix wieder rausgeschoben? Ist dies die Absicht des Markierens?

version-control svn

— Wayne Molina
quelle

5

Außerhalb der Box-Strategie: Wechseln Sie zu Git.

— Rein Henrichs

Wenn das eine Option wäre, würde ich es tun (oder Mercurial, da wir ein Windows-Shop sind). Ich denke, ich würde noch mehr Widerstand leisten, wenn ich versuchen würde, auf ein völlig neues Versionsverwaltungssystem umzusteigen, als wenn ich versuchen würde, zumindest eine angemessene Umgebung mit SVN einzurichten.

— Wayne Molina

2

Obwohl ich von DVCS begeistert bin, ist Subversion ein gutes Werkzeug. CVS oder eine andere Lösung ohne Ordnerversionierung wäre schlechter.

— Matthew Rodatus

2

@ Wayne M - Sie können feststellen, dass es tatsächlich umgekehrt ist. Es ist möglicherweise einfacher, Benutzer dazu zu bringen, sich für eine vernünftigere Umgebungsstruktur anzumelden, wenn sie dadurch alle Vorteile der Verwendung eines DVCS nutzen können. Als Übergang sollten Sie in Betracht ziehen, die Leute dazu zu bringen, einen billigen lokalen Verzweigungs- / Repo-Zugriff mit gitsvn oder hgsubversion auszuprobieren. Sobald sie an die Tools gewöhnt sind, besteht möglicherweise ein gruppenweiter Wunsch, für die primären Repos zu einem DVCS zu wechseln.

— Mark Booth

5

Wenn Sie einen einheitlichen Erstellungsprozess wünschen, müssen Sie Zweige / Tags / Trunk wie folgt im Stammverzeichnis platzieren:

branches/
tags/
trunk/
  dev/
    ...

Wenn Sie keinen einheitlichen Erstellungsprozess benötigen, können Sie Zweige / Tags / Amtsleitungen in jedes Projekt einfügen, wenn Sie möchten. Es kann jedoch schwierig sein, zu einem einheitlichen Build zu migrieren, nachdem Sie sie in jedes Projekt eingefügt haben. Ein einheitlicher Build bietet Vorteile, z. B. die Notwendigkeit, gemeinsam genutzte Komponenten in Projekten zu veröffentlichen - sie sind alle Teil des Builds.

Persönlich mag ich einen einheitlichen Erstellungsprozess. Außerdem denke ich nicht, dass Sie ein "Entwickler" -Projekt haben sollten. Sie sollten Projekte direkt unter Trunk haben und dann Trunk in einen Dev-Zweig verzweigen. Verwenden Sie Tags für Releases. Zum Beispiel würde ich es so machen:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

— Matthew Rodatus
quelle

1

Ein einheitlicher Build bietet Vorteile, z. B. die Notwendigkeit, gemeinsam genutzte Komponenten in Projekten zu veröffentlichen - sie sind alle Teil des Builds.

— Matthew Rodatus

2

Wenn Sie mehrere einheitliche Builds benötigen, erstellen Sie jeweils Verzeichnisse unter Trunk. Aber ich würde keinen "Entwickler" nennen - das geht besser mit einem Zweig. Beispielsweise haben Sie möglicherweise zwei primäre Entwicklerorganisationen - eine, die mit Gerätetreibern arbeitet, und eine, die auf der Unternehmenswebsite funktioniert. Sie möchten wahrscheinlich zwei separate einheitliche Builds.

— Matthew Rodatus

1

Was die Codestruktur innerhalb von svn betrifft, ist dies eine wirklich persönliche Entscheidung.

Ich würde vorschlagen, dass die Projekte, wenn sie verwandt sind oder Code gemeinsam nutzen, einen gemeinsamen Trunk wünschen. Wenn sie unabhängig sind, möchten sie separate Amtsleitungen oder sogar separate Repositorys. Wenn Sie einem Dritten jemals eine Kopie des SVN-Verlaufs für ein Projekt zur Verfügung stellen müssen, ist es viel einfacher, wenn es sich in einem separaten Repository befindet.

In Ihrem Fall klingt das oben skizzierte Layout also vernünftig, da Sie gemeinsam genutzten Code haben und möchten, dass Zweige / Tags diesen gemeinsam genutzten Code enthalten.

Ihre Beschreibung der Verwendung von Tags und Zweigen klingt äußerst sinnvoll und ist die Art und Weise, wie ich erwarten würde, dass svn verwendet wird. Das ist in der Tat die Absicht zu markieren, wie ich es verstehe. Übrigens in SVN-Tags und -Zweigen ist eigentlich dasselbe, aber die Terminologie wird so angewendet, wie Sie sie angewendet haben.

Persönlich würde ich auch die Einschränkung hinzufügen, dass alles, was für den Kofferraum bestimmt ist, gebaut werden muss, atomar sein muss und keine Komponententests brechen sollte. Zweige sind für unfertige Arbeiten in Arbeit. Ich würde erwarten, dass der Kofferraum zu jedem Zeitpunkt ein potenzieller Release-Kandidat ist.

— Luke Graham
quelle

Wollen Sie damit sagen, dass nur getesteter, produktionsbereiter Code im Trunk sein sollte? Ich denke, jeder Code, der festgeschrieben wird, sollte Tests erstellen und wahrscheinlich bestehen, und Trunk-Code sollte natürlich Tests bestehen. Es scheint jedoch, dass der Zweck von SVN darin besteht, die Entwicklungshistorie zu verfolgen, und das ist einfacher, wenn es nicht auf mehrere Zweige aufgeteilt ist. Vielleicht sollte es einen Zweig geben, in den Sie Trunk zusammenführen, wenn sich Trunk in einem getesteten, produktionsbereiten Zustand befindet?

— Herr Jefferson

0

Das Folgende ist der beste Weg, um ein Subversion-Repository zu erstellen

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

Auf diese Weise können Sie einzelne Projekte selbst überprüfen.

Wenn Sie alle drei Projekte auschecken und einen einheitlichen Build mit einem monolithischen Build-Skript / System erstellen möchten, untersuchen Sie dies mithilfe eines Master- Moduls mit svn: externals, das alle anderen Projekte dem Master zuordnettrunk .

Dies ist auf den ersten Blick komplizierter, aber es ist der am besten zu wartende und idiomatischste Weg, um dieses Problem mit Subversion zu lösen.

2

Ich bin absolut anderer Meinung. Das Repository speichert nicht nur Code. es kommuniziert die Organisationsstruktur und die Beziehung zwischen Komponenten; Es ist ein wichtiger, wenn auch impliziter Kommunikationskanal. Wenn Sie jedes Projekt einzeln aufteilen, führen Sie künstliche und unnötige Kommunikationsbarrieren ein.

— William Payne