Versionskontrolle?

[Felix G]

Sorry wenn ich deinen thread infiltriere, aber wo wir hier gerade bei Versionskontrolle sind hätte ich auch noch eine Frage...

Wir benutzen in der Firma momentan Visual Source Safe (schlimmer gehts kaum, ich weiss), es gibt aber erste Überlegungen ob wir eventuell auf was besseres umsteigen (vor allem weil die VSS Datenbank wohl in absehbarer Zeit eine kritische Größe erreicht).

Die offensichtlichste Lösung wäre natürlich der Team Foundation Server von Microsoft, aber es gäbe da ja auch noch Subversion, Mercurial und Git (um nur mal die wichtigsten zu nennen). Welches System für uns am besten geeignet wäre, interessiert mich dabei aber erstmal garnicht (muss man ausprobieren und dann entscheiden).


Mein Problem ist ein spezielles Feature von VSS welches wir exzessiv nutzen, das aber keiner der 4 Kandidaten zu haben scheint: shared files

Unsere VSS Datenbank ist vollgestopft mit vielen unterschiedlichen Projekten, wobei es allerdings viele Dateien gibt die in mehreren (einige sogar in allen) Projekten genutzt werden. Bei VSS kann man eine solche Datei einfach "sharen", sagen wir mal in den Projekten A, X und Y. Ändert man diese Datei dann in einem der Projekte, dann wirkt sich das auch auf die anderen Projekte aus.


Wie würde man das in TFS, SVN, Mercurial oder Git lösen?

[TheDarkRose]

Also ich selbst bevorzuge Git, weis es eben nicht nur eine simple Arbeitskopie erstellt, sondern das ganze Repository klont. Damit hat man immer die komplette Commithistory dabei, kann auch Commits machen wenn man offline ist, und da es bei Git ja sehr gut mit Branching zu arbeiten ist, benutze ich das auch viel. Und man kann dann auch mal schnell lokal einen Branch erstellen, um gewisse Dinge (auch über länger) auszuprobieren, ohne das man diesen Branch in ein zentrales Repo pushen müsste. Somit muss nicht jeder deine Gedankenspiele mitbekommen, wenn man das nicht will. Auf gut deutsch, Git kann sehr agil sein.

Zu deiner Sache mit den den shared projects. Bei SVN heißt das svn-externals und bei Git sub-modules. Ob man in einem so eingebunden Unterrepo(/-projekt) die Dateien direkt bearbeiten kann und ins richtige Projekt commiten, hängt von den richtigen Zugriffseinstellungen ab.

Kennst du zufällig Github? Falls ihr euch für Git entscheidet und eure Firma nicht auf professionellen Support verzichten möchte, könntet ihr euch Github:FI (Firewall Install) ansehen. Das ermöglicht dir eine fast Github ähnliche Umgebung und auch so einfache Administration der Repositorys und Commiter im eigenen Unternehmen und auch nach außen abgeschottet.

[Felix G]

Zu deiner Sache mit den den shared projects. Bei SVN heißt das svn-externals und bei Git sub-modules. Ob man in einem so eingebunden Unterrepo(/-projekt) die Dateien direkt bearbeiten kann und ins richtige Projekt commiten, hängt von den richtigen Zugriffseinstellungen ab.

Also wenn ich das richtig verstehe müssten wir dann die geshareten Dateien erstmal zu neuen repositories zusammenfassen, und diese dann in den anderen einbinden, richtig? Und die Dateien würden dann in entsprechenden Unterverzeichnissen auftauchen? Das wäre einerseits schön, weil wir damit etwas mehr Ordnung in die Sache bringen würden, aber andererseits müsste man tonnenweise #includes anpassen, da sich der Pfad vieler Dateien dadurch ändern würde (d.h. nach der Migration der VSS Datenbank wäre nochmal viel Handarbeit notwendig um wieder auf einen vergleichbaren Stand zu kommen).

Kennst du zufällig Github? Falls ihr euch für Git entscheidet und eure Firma nicht auf professionellen Support verzichten möchte, könntet ihr euch Github:FI (Firewall Install) ansehen. Das ermöglicht dir eine fast Github ähnliche Umgebung und auch so einfache Administration der Repositorys und Commiter im eigenen Unternehmen und auch nach außen abgeschottet.

Github kenne ich nur vom Namen her, aber professioneller Support ist für uns eigentlich auch nicht so wichtig (wir sind eine relativ kleine Firma, mit nur einer Handvoll Entwicklern).

[danimath]

Moin Felix,

Also wenn ich das richtig verstehe müssten wir dann die geshareten Dateien erstmal zu neuen repositories zusammenfassen, und diese dann in den anderen einbinden, richtig? Und die Dateien würden dann in entsprechenden Unterverzeichnissen auftauchen? Das wäre einerseits schön, weil wir damit etwas mehr Ordnung in die Sache bringen würden, aber andererseits müsste man tonnenweise #includes anpassen, da sich der Pfad vieler Dateien dadurch ändern würde (d.h. nach der Migration der VSS Datenbank wäre nochmal viel Handarbeit notwendig um wieder auf einen vergleichbaren Stand zu kommen).

Das sollte eigentlich der richtige Weg sein. Jajaja - das ist erstmal mit Arbeit verbunden; wie Du selbst sagst, bringt das mehr Ordnung ins System. Aber so'n Umstieg kann auch als Chance gesehen werden sich von Altlasten zu befreien.

viele Grüße
Andreas

[TheDarkRose]

Also wenn du die sub-modules richtig einbindest, dann dürfte sich nichts am Pfad ändern und es fallen keine #include Änderungen an.