Wir haben Anfang des Jahres produktiv von Visual-Source-Safe (VSS) auf den Team Foundation Server (TFS) umgestellt.
Ich stand vor der Frage ob ich den bisherigen Source-Safe Inhalt komplett in den TFS übernehme und wie die eigentliche Migration auf den TFS möglichst schnell ablaufen kann.
In älteren Blog Artikeln habe ich ja bereits von dem Problem berichtet, dass wir sehr viel auch mit Shares unter VSS gearbeitet haben. Ich hätte hier sowieso tricksen müssen und die eigentliche Umstellung der Projekte in eine Struktur, die keine Shares mehr verwendet wollte ich dich lieber unter Nutzung des TFS durchführen.
Die Entscheidung viel also so aus:
- Übernahme des aktuellen Programmstandes in das TFS System
- Keine Übernahme der alten VSS Daten mit dem VSSConverter
- Überarbeitung der Projektstruktur so dass, keine Datei-Shares mehr benötigt werden. Hierbei werden entsprechende übergeordnete Common Verzeichnisse verwendet.
- Entzerrung der Gesamten Projektstruktur so, dass auch die Verwendung einer Master-Solution möglich wird.
- Beibehalten der alten VSS Daten in einem Backup System, für evtl. Hotfixes der letzten Version und einige Legacy Projekte
Ich gebe zu, dass ich misstrauisch war. Auf die Historie des Source Control Systems nicht weiter als zum letzten Release zurückgreifen zu können erschien mir als großer Nachteil. Gerade weil wir hauptsächlich Projekte und Programmteile haben, die zum Teil schon auf 20 Jahre Geschichte zurückblicken und immer noch weiter entwickelt werden.
Letzten Endes haben aber alle Team Mitglieder bisher klar gesagt: „Schade, dass wir diesen Schritt au den TFS nicht eher gemacht haben“.
Im Nachhinein vermisst keiner die gesamte VSS Historie, der Projekte. Wer muss, der kann noch im alten VSS Backup-System stöbern. Aber das war bisher nur in einem einzigen Fall wichtig und hilfreich.
Ich kann aus meiner Sicht also dazu raten, einfach einen Cut mit dem aktuellen System zu machen und mit dem aktuellen Programmstand einfach in das TFS System einzuchecken und einzutauchen. Sich zwei Tage und mehr mit dem VSSConvert herumzuschlagen (wie ich es zum Teil schon gehört habe), ist aus meiner Sicht heute vertane Zeit.
Kann ich nur bestätigen. Letztlich war der Umstieg auch ein guter Zeitpunkt, die seit Jahren eingefahrene Projektstruktur einmal auf den Prüfstand zu stellen und an aktuelle Gegebenheiten anzupassen.
Hallo Martin,
auch ich kann das nur bestätigen. Leute hängen viel zu seh an der Vergangenheit. Ich selbst bin aber der festen Überzeugung, dass ein sauberer Neuanfang ohne die alten Strukturen und Probleme viel mehr Vorteile bring als bin in alle Ewigkleit nachschauen zu können, was wann von wem an einer Datei verändert wurde. Und wie du berichtet hast, hat man das ja immer noch im alten System und sollte es in einem seltenen Fall wirklich nötig sein, kann man den geringen Mehraufwand dort nachzuschauen auch in Kauf nhemen. Wir haben bei uns auf diese Weise sogar die Migration von TFS 2005 nach TFS 2008 durchgeführt und ich bin froh, einige Altlasten auf deisem Wege beseitigt zu haben.
Ich würde auch jedem empfehlen, egal ob es technisch funktioniert oder nicht: Ab mit den alten Zöpfen und einen suaberen Neuanfang gewagt.
Also hier muss ich beim lesen doch einmal widersprechen. Mein Umstieg von CVS nach Monotone lief auf der einen Seite sauber durch, besser als meine Tests mit Subversion und ich wollt die Neuordnung zu einer Mainsolution gleich mit dem Umstieg haben. Auch das lief problemlos.
Wobei man dazu sagen muss das dies mehr ein Verdienst von CVS war. Man konnte da nämlich einfach die Verzeichnisse neu anordnen (direkt auf dem server 😉 ) und hinterher musste man es nur noch in den Solutions anpassen.
Ansonsten bin ich mittlerweile noch immer sehr froh das ich meine Historie behalten konnte ohne parallel auf einem Backupserver suchen zu müssen.
Bei mir ist es leider so, das auch eine alte Variante in der Welt rumschwebt und ich sie ab und an doppelt pflege. Selten aber es kommt doch vor.
Den Cut hät ich mittlerweile wahrscheinlich 4x machen können, jeweils mit den Umstiegen von Vc6 zu 2003, dann 2005 und nun 2008, aber so ist es mir am Ende doch lieber und trotz riesigem Repository ist Monotone immer noch fix genug. Was auch einer der Gründe für mich damals war direkt dahin umzusteigen.