Laden...

SVN Repositoryaufbau

Erstellt von thomas.at vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.299 Views
T
thomas.at Themenstarter:in
111 Beiträge seit 2005
vor 14 Jahren
SVN Repositoryaufbau

Hallo

wir wollen jetzt in der Firma (endlich) ein Sourcecontrolsystem einführen (GIT-System). Ich habe aber das Problem, das ich nicht weiß, wie ich dieses aufbauen soll. Ich habe z:B. folgene Projekte in einer Solution:

    
  Server
  Server_BL
    -- Oracle
      -- Zugriff auf Tabelle a
      -- Zugriff auf Tabelle b
      usw.
    -- SQL
      -- Zugriff auf Tabelle a
      -- Zugriff auf Tabelle b
      usw.
  Interfaces
  Remoting
  Client
    -- Plugin A
    -- Plugin B
    usw.

Jetzt greifen die Plugins vom Client über Interfaces und Remoting auf die Zugriffe der DB's zu. Ein Plugin kann sowohl auf Oracle als auch auf SQL zugreifen. Jetzt war meine Überlegung, das ich ein Repository für jeden Bereich (Server, Server-BL...) anlege und dort mit verschiedenen Branches die Zugriffe auf Oracle und SQL oder die Plugins mache. Wenn ich dies tue habe ich aber das Problem, wenn ich für ein Plugin sowohl für SQL und Oracle mache. Dann müsste ich ja dauernd zwischen den beiden Branches hin und her switchen. Oder wie läuft das ganze richtig ab?

lG
Thomas

4.506 Beiträge seit 2004
vor 14 Jahren

Hallo thomas.at,

ich glaube nicht, dass ein Repository in der Sourcecodeverwaltung für Komponententrennung gedacht ist.

Für mich war mein bisheriges Verständnis, dass wenn ich aus einem Repository einen bestimmten Quellcodestand auschecke, dass ich den Quellcode kompilieren kann und dann mein Produkt in der angeforderten Version habe.

Also mal grob erklärt:

  • Ein Repository sind für mich eigenständige Produkte bzw. Solutions
  • Ein Branch ist für mich ein zwischenzeitlich separater Quellcodestrang, der eine definierte Ausgangsbasis hat und ggf. in den Hauptstrang zurückgemergt wird
  • Ein Trunc (den sollte man immer definiert haben) ist der Hauptstrang, in den auch alle Branches zurückfliessen müssen, sofern man die Entwicklung nicht verwerfen will
  • Nur aus dem Trunc werden Release-Versionen gezogen
  • Plugins werden für die Quellcodeverwaltung als benötigter Quellcode angesehen, auch wenn er separat kompiliert werden muss

Ich würde Dein gesamtes Konstrukt (Server_BL, Interfaces etc.) allessamt in ein Repository stecken. Falls parallel Dinge entwickelt werden, dann würde ich einen neuen Branch aufmachen.

Ich hoffe ich habe es verständlich rübergebracht?

Grüße
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

T
thomas.at Themenstarter:in
111 Beiträge seit 2005
vor 14 Jahren

Hallo Norman-Timo

so hatte ich dies auch im ersten Entwurf gemacht. Nachdem ich aber immer über die Branches gelesen hatte, glaubte ich dies nach meinem ersten Post so aufteilen zu müssen. Aber wenn man es doch alles in einem durch macht dann kann ich ja munter so weiter arbeiten. Vielen Dank für Deine Antwort.

lG
Thomas

1.820 Beiträge seit 2005
vor 14 Jahren

Hallo!

Ich hab' mein Repository zusätzlich noch in 3 Hauptebenen unterteilt:
*libs: Für Klassenbibliotheken *projects: Klar, für die lauffähigen Programme *vendor: Externe Programme (egal, ob mit oder ohne Quellcode)

Evtl. kann man noch Ebenen für Testprojekte, sonstige Dateien (Grafiken, Anleitungen, ...) oder Hilfsprogramme hinzufügen, ganz nach eigenem Geschmack.

Nobody is perfect. I'm sad, i'm not nobody 🙁

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo,

Also wir haben mehrere Repositories:

  1. Ein Repository für alle *.sln-Dateien und alle Dokumente/Dateien die auf diese Ebenen gehören (die also direkt in die *.sln-Datei eingebunden sind und nicht in eine *.csproj (oder Eintsprechung))

  2. Ein Repository für jede *.csporj-Datei (oder Entsprechung)

  3. Ein Repository für alle Binärdateien (in allen Major- und Minor-Versionen)

  4. haben wir, da diese Daten relativ kein sind und vom Management/Marketing/PR-Abteilung/usw. verwendet wird und die nicht im Quell-Code herum spielen sollen, aber Ihre Änderungen auch dokumentiert sein sollen (und evtl. auch in die *.sln einfliesen).

  5. jedes "Projekt" aus dem eine Assembliy entsteht hat ein Repository, da das Repository in SVN eine gemeinsam "Versionsnummer" (aka. Revisionsnummer) hat und in .Net die kleinste Versionierbare ein heit das Assembly ist.

  6. haben wir, weil wir so viele Parallele Installationen mit verschiedenen DLLs in verschiedenen Versionen haben, dass wir für Support-Fälle alle Major- und Minor-Versionen gleichzeitig brauchen ( 🙁 )

Dazu Verwante und eventuell nützliche Themen:
Quellcodeverwaltung mit Subversion
Ordner- und Namespacestruktur
Ordner- und Namespacestruktur

Zum zweiten Punkt mit den Branches:
Wenn du zwei Varianten einer "Funktion" hast, die du parallel anbietest, aber beide nicht im gleichen Quellcode sind, hast du eigentlich einen Design fehler. Beide "Funktionen" sollten das selbe interface implementieren und bei der Verwendung ausgetauscht/eingesetzt werden können.
=> Das heißt für dein Beispiel, dass ein PlugIn nicht weiß mit welche Implementation des Datenzgriffs (Oracle oder MSSQL) es arbeitet und beide parallel im SVN enthalten sind (in verschiedenen Namespaces).

Gruß
Juy Juka

T
thomas.at Themenstarter:in
111 Beiträge seit 2005
vor 14 Jahren

Hallo Juy Juka

also die Plugins wissen nicht auf welchem System die Tabelle liegt, dies ist schon über Interfaces geregelt. Nur die Serverbusinesslogik ist geteilt, eben in SQL oder Oraclezugriffe. Das Problem ist eben die Erweiterung dieser Server-BL. Hier kann es gleichzeitig zu Änderungen in beiden Bereichen kommen. Ich habe meine Serverlogik so aufgebaut, das für jede Tabelle ein eigenes Projekt vorhanden ist. Zusammen mit meinen Plugins, Libraries usw. ergeben sich derzeit 145 Projekte. Nach Deinem Aufbau wären das dann auch soviel Repositories. Wäre das dann aber nicht ein großer Aufwand alle Änderungen zu Comitten und zu Pushen, oder gibt es dann eine Möglichkeit dies Batchgesteuert zu machen?

Thomas

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo tomas.at,

Der Oracle und der MSSql Teil sollten ja eigentlich Parallel existieren, wie ich schon im anderen Post beschrieben habe. Daher sollte man beide parallel bearbeiten können. (Wenn du änderungen an der Schnittstelle hast, die von beiden Implementationen erfüllt werden müssen, hast du halt einen BrackingChange und eine neue Major-Version.)

Das kommt auf den Client an, den man für den Commit verwendet.
Und wenn du alle 145 Projekt auf einmal hoch spielen musst, müsste ja eh etwas falsch gelaufen sein. Normal macht mein eine Trennung ja, damit man nicht alles gleichzeitig Ändern muss.
Batch es gar kein Problem, wenn der verwendet Client sich über Console steuern lässt (wir haben TortoiseSVN und da geht das).

Gruß
Juy Juka