Ich plane in der nächsten Zeit Visual Source Safe (VSS) abzulösen. Da wir alle Hauptprojekte (bis auf einigen legacy Kram) auf VC++ 2005 bearbeiten und die entsprechenden Visual Studio Team System Lizenzen haben beabsichtigen wir auch den Team Foundation Server (TFS) einzusetzen.
Einen Team Foundation Server kaufen müssen wir auch nicht, denn wir haben nicht mehr als 5 Clients.
Vorteile:
- Integration auch in ältere Systeme ist kein Problem! Für VC6, VB6, VS.NET 2003 gibt es entsprechende Plug-Ins! Das ist schon mal genial. Also können wir theoretisch sogar alle legacy Projekte konvertieren und mit den alten Tools weiterarbeiten.
- Alles wird in einem SQL-Server gehalten. Endlich!
- Die Projekt Dokumente sind gleich in dem entsprechenden Share Point mit gehalten (leider noch WSS 2.0)
- Einchecken mehrere Dateien werden direkt zu einem Vorgang zusammengefasst.
- Direktes Bug-Tracking und einfache Projektierung ist möglich ohne externe Hilfsmittel.
Beim evaluieren der Features habe ich mir schon die Hände gerieben. Allerdings gibt es da eine wirkliche fette Kröte die ich schlucken muss. Mein geliebtes „Sharing“ unter VSS gibt es unter dem Source Control System von TFS nicht ❗
Wir haben einiges an gemeinsamen Code, den wir nicht in Libraries oder DLLs zusammengefasst haben. Da sind einige nette Template Klassen etc., spezielle Header und andere nette Code-Snipplets. Alle diese Code Teile waren in einem kleinen Projekt zusammengefasst und jeder Entwickler konnte diese wahlfrei in sein Projekt sharen. Das ist und war extrem bequem. Mit dem Drawback, dass eine zentrale Code Änderung alle Projekte beeinflusst und evtl. bricht kann man leben.
Man muss einfach regelmäßig Ohrfeigen verteilen für Entwickler die nicht testen und Kerker bei Brot und Wasser androhen… 😉
Unter TFS ist es damit vorbei. Einziger Ausweg wie ich ihn aktuell sehe ist es, die entsprechenden Codeteile einzubranchen in die anderen Projkete. D.h. aber das man die aktuelle Version (und den evtl. gewünschten Fix) nur mit einem Merge bekommt, was wieder nicht unbedingt automatisch geht, man muss also Hand anlegen was man evtl. eben auch vergisst.
Mal sehen vielleicht fällt mir da noch was anderes ein. Anonsten sieht das ganze sehr vielversprechend aus.
Hi,
schieb doch einfach alle geteilten Codedateien in ein Common-Verzeichnis, welches von jedem Projekt eingebunden werden kann.
Das einzige was sich für die Projekte ändert ist der Pfad, der zu der Datei führt.
Wir haben hier früher auch mit VSS und sharing gearbeitet und es dann mit dem Common-Verzeichnis gelöst. Klappt hervorragend.
Viele Grüße.
Dann gehört aber dieses „Common“ Verzeichnis nicht zum Projekt!
Oder wie verstehe ich das?
Man hat dann ein eigenes „Common-Projekt“ in dem die entsprechenden Dateien drin sind. Das empfinde ich aber als unübersichtlich.
Wie steht es denn mit CPP Dateien, die in dem entsprechenden COMMON Pfad drin sind. Wie gehören, die dann zu meinem Projekt?
Bedenke ich habe ca. 90 Projekte, die aktiv sind.
Oder habe ich was falsch verstanden?
Den bharry brauch ich Dir wahrscheinlich nicht empfehlen, oder? Du hast doch bestimtm schon mit ihm gesprochen. Er ist, IIRC, verantwortlich fuer den MS-eigenen TFS (Dogfood-Server).
Ich kannte ihn noch nicht. Danke für den Tipp! Carsten!
Das Common-Verzeichnis gehört nicht zum Projekt. Du fügst einfach die Dateien zu Deinem Projekt hinzu, die Du brauchst. Die tauchen dann ja trotzdem im SourceTree im VS auf.
Im vcproj-File steht dann so was wie: RelativePath=“..\..\Common\DeineDatei.cpp“
Einzig den Include-Pfad, der auf das Common-Verzeichnis weist mußt Du Deinem Projekt noch beibringen. Aber das läßt sich ja durch ein PropertySheet sehr elegant lösen.
Im Prinzip so:
SourceCode
|-Common
|-Projects
|-Project1
|-Project2
|-…
Wir haben zwar keine 90 Projekte, aber 30 sind es bestimmt. Wie gesagt, klappt sehr gut. Weiterer Vorteil ist, dass Du die Dateien auch nur einmal auf der Platte hast und nicht in jedem Projektverzeichnis…
Der Tree ist verrutscht… Project1 und Project2 liegen unter Projects… 🙂
SourceCode
|-Common
|-Projects
–|-Project1
–|-Project2
–|-…
Der Nachteil ist auch klar, das Projekt ist immer Abhängig von dem Common Pfad und ob man den auch in seinem Workspace hat. Wenn man jetzt noch méhere Gruppen hat wird es ganz kompliziert.
Bisher ist es einfach in VSS! Man holt das Projekt entsprechende dem letzten Stand oder einem Label und hat alles was man braucht. Nichts muss angepasst werden, auch nicht in der Entwicklungsumgebung oder im Projekt.
Ich werde mir mal die Whitepapers zu Gemüte führen.
Herzlichen Dank für das Feedback!