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
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:
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!”
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
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 🙁
Hallo,
Also wir haben mehrere Repositories:
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))
Ein Repository für jede *.csporj-Datei (oder Entsprechung)
Ein Repository für alle Binärdateien (in allen Major- und Minor-Versionen)
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).
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.
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
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
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