Visual Source Safe -> TFS-Migration

StackOverflow https://stackoverflow.com/questions/29838

Frage

Hier arbeiten wir seit etwa 10 Jahren mit einer Reihe von Visual Source Safe-Repositories.

Jetzt möchte ich Sourcesafe loswerden und zu Team Foundation Server wechseln.

Haben Sie irgendwelche Tipps oder Tricks für mich, bevor ich mit dieser Migration beginne?Auf welche Dinge muss ich achten?

Ich bin sicher, dass diese Migration dazu führen wird, dass unsere Arbeitsgewohnheiten in irgendeiner Weise geändert werden müssen.Glauben Sie, dass diese Veränderungen ein Problem für die Organisation darstellen könnten?Stellen Sie sich eine Gruppe von etwa 20 .NET-Entwicklern an einer einzigen Site vor.

War es hilfreich?

Lösung

Ich habe gerade gegoogelt, aber diese Komplettlösung scheint eine gute Referenz zu sein und erwähnt das Tool VSSConverter, das Ihnen helfen soll, die Migration so schmerzlos wie möglich zu gestalten.

Eines möchte ich allerdings empfehlen:Sicherung.Sichern Sie alles, bevor Sie dies tun.Sollte etwas schief gehen, ist Vorsicht besser als Nachsicht.

Meine Links werden nicht angezeigt.Das ist die Adresse: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

Andere Tipps

Es gibt verschiedene Möglichkeiten, wie Sie migrieren können.Das Tool ruft Ihren Verlauf usw. ab.vorbei, aber der pragmatischere und einfachere Weg besteht darin, VSS als Verlaufsarchiv zu sperren und neu zu beginnen:

  1. Lassen Sie alle Änderungen in VSS einchecken, stellen Sie sicher, dass alles erstellt wird usw.
  2. Alle VSS-Datenbanken auf „gesperrt“ setzen (nur Leserechte für alle Benutzer)
  3. Holen Sie sich die neuesten Informationen zur gesamten VSS-Datenbank in einen „sauberen“ Ordnersatz auf einer Workstation
  4. Checken Sie alle Dateien von der Workstation in TFS ein

Für die Historie vor der Konvertierung müssen die Leute auf VSS zurückgreifen, aber nach ein oder zwei Wochen ist es realistischerweise unwahrscheinlich, dass das so oft vorkommt.Und Sie wissen, dass der Verlauf in VSS korrekt ist und durch den Konvertierungsprozess nicht beschädigt wird.

Beachten Sie, dass TFS die gemeinsame Nutzung von Dateien zwischen verschiedenen Projekten nicht unterstützt, wie dies bei VSS der Fall ist.Wenn Sie über solche freigegebenen Dateien verfügen, wird die Verknüpfung zwischen ihnen während der Migration unterbrochen, was zu zunächst identischen, nun aber unterschiedlichen Dateien in jedem Projekt führt.Aktualisierungen einer dieser Dateien in TFS werden nicht mehr auf die Kopien in den anderen Projekten übertragen.

Wenn Sie sich für die Verwendung des Tools „VSSConverter.exe“ entscheiden, das im Lieferumfang von Visual Studio Team Foundation Server enthalten ist, sollten Sie es installieren TFS 2008 SP1 Erstens, da es eine Reihe von Verbesserungen enthält, wie im Detail beschrieben auf diesem Blog vom Migration-Tools-Team.

Einige der wichtigsten Merkmale der Version sind:

Beseitigung von Namensraumkonflikten.Ich habe zuvor darüber als "das umbenennende Problem umbenannt" gebloggt und wir haben den Konverter behoben, um Dateien mit überlappenden Namespaces korrekt zu migrieren.Dies war der größte Schmerzpunkt für die meisten Benutzer, die versuchen, frühere Versionen des Tools zu verwenden.

Automatische Neubindung der Lösung. In dieser neuesten Version werden VS -Lösungsdateien automatisch auf die 9.0 -Version aktualisiert und wieder auf die Versionskontrolle überprüft.Zuvor mussten Benutzer dies manuell tun.

Korrektur von Zeitstempelkonsistenzen.Die Verwendung von Kundenzeitstempeln durch VSS kann dazu führen, dass Revisionen in der entgegengesetzten Reihenfolge erfasst werden, in der sie tatsächlich aufgetreten sind.Das Tool erkennt dieses Problem nun an und migriert die Änderungen, die zuvor fehlschlagen würden.

Verbesserte Protokollierung.Obwohl wir viele Probleme behoben haben, hilft es Benutzern, die Probleme zu begegnen, die Probleme zu diagnostizieren, eine bessere, detailliertere Protokollierung.

Wir sind derzeit dabei, dies in meinem Hauptberuf zu tun.Tatsächlich nehmen wir die Umstellung in etwa einem Monat vor.Ich bin maßgeblich an der Migration beteiligt und habe einen großen Anteil daran, warum wir SourceSafe verlassen.Um bei der Migration zu helfen, habe ich das verwendet Visual Studio® Team System 2008 Team Foundation Server und Team Suite VPC-Image.Es war sehr nützlich.Das Image enthält auf Anhieb eine voll funktionsfähige TFS-Installation, mit der Sie spielen und eine Demo durchführen können.Es umfasst auch Hands on Labs und in einem der Labs wird das VSS -> TFS-Migrationstool ausgeführt.Wenn Sie ein MSDN-Abonnement haben, besteht der nächste Schritt nach dem Spielen mit dem Image darin, die TFS Small Team Edition zu installieren, die Ihrem Abonnement beiliegt.

Beachten Sie unbedingt, dass Sie die neuesten Service Packs für Visual Studio 2008 und das .NET Framework auf dem Image installiert haben.Die Service Packs haben einige lästige Fehler behoben und die Benutzerfreundlichkeit des Systems definitiv verbessert.Wir verfügen über eine ziemlich große SourceSafe-Datenbank mit über 90 Projekten und die Fertigstellung des Migrationstools dauerte etwa 32 Stunden.Zuerst habe ich zum Testen ein Backup unserer Sourcesafe-Datenbank erstellt.Dann habe ich die Migration auf die Test-Sourcesafe-Datenbank durchgeführt.Anschließend habe ich den Quellbaum in TFS überprüft und alles wurde einwandfrei übertragen.Wir haben den gesamten Verlauf unserer Quelldateien von VSS behalten, was großartig war.Es ist nicht nötig, diese stinkende VSS-Datenbank nach der Inbetriebnahme weiter zu behalten.

Wir gehen die Migration schrittweise vor.Zuerst die Quellcodeverwaltung und unsere Entwickler damit vertraut machen.Danach werden wir die Qualitätssicherung und die Geschäftsanalysten migrieren, um die Funktionen zur Arbeitsaufgabenverfolgung zu verwenden.

Mein Rat ist, die Migration schrittweise durchzuführen.Machen Sie nicht zu viel auf einmal.Geben Sie den Personen, die das System nutzen werden, Zeit für die Einarbeitung.

Der VSS-Konverter ist alles andere als eine perfekte Lösung.Und es gibt erhebliche Unterschiede zwischen der 2005er und der 2008SP1-Version des Konverters.

Beispielsweise gibt es in einer VSS-Datenbank, die schon lange verwendet wird, eine große Anzahl von Benutzern, die zu VSS beigetragen haben.Viele dieser Benutzer haben die Organisation schon vor langer Zeit verlassen und verfügen daher nicht mehr über Domänenkonten.TFS erfordert die Zuordnung von VSS-Benutzern zu Domänenkonten. Sie müssen also entscheiden, ob Sie alte Benutzer einem einzelnen „Dummy“-Domänenkonto oder einem aktuellen Teammitglied zuordnen möchten.

Darüber hinaus erfordert VSS Converter 2008, dass diese Domänenkonten gültige TFS-Konten sind.Der Konverter von 2005 erzwingt dies jedoch nicht.

Wenn Ihr VSS-Verlauf wichtige Ordnerverschiebungen enthält, verlieren Sie wahrscheinlich den gesamten Verlauf vor dieser Verschiebung.Wenn Sie beispielsweise einen Ordner an einen neuen Speicherort verschieben und dann den vorherigen übergeordneten Ordner löschen, geht der gesamte Verlauf verloren.Weitere Erklärungen finden Sie in diesem Artikel:http://msdn.microsoft.com/en-us/library/ms253166.aspx

Bei einer Migration, an der ich beteiligt war, hatten wir eine 10 Jahre alte VSS-Datenbank, deren gesamter Verlauf vor 6 Monaten verloren ging.Dies war auf umfangreiche Aufräumarbeiten zurückzuführen, die vor 6 Monaten durchgeführt wurden.

TFS-Konvertierungstool <-- Verwenden Sie dies

Ich verwende dieses Tool bereits seit einiger Zeit. Die Ergebnisse sind ziemlich zufriedenstellend, da es auf Wunsch auch mit dem Verlauf der Änderungssätze von SourceSafe geliefert wird.

Wie dem auch sei, Sie sollten bei der Verwendung dieses Tools immer auf Fehler und Warnungen im Protokoll achten und prüfen, ob alles in Ordnung war bzw. in Ordnung war.

Es wird empfohlen, vor der Ausführung auch eine SS-Analyse durchzuführen.

Ich hoffe es hilft

Gute Anleitung dabei von meinem ehemaligen Kollegen Guy Starbuck.Eine weitere Sache, die Sie bei diesem Ansatz hinzufügen sollten: Möglicherweise haben Sie sich im Laufe der Zeit entschieden, dass Sie die Art und Weise, wie Ihre Anwendung organisiert ist (Ordner usw.), umgestalten möchten, und dies gibt Ihnen die Möglichkeit, dies zu tun.

Ich habe Situationen erlebt, in denen wir eine Lösung willkürlich und ohne nachzudenken organisiert haben (ganz zu schweigen von großen Änderungen in der Anwendung), was zu dem Wunsch geführt hat, die Dinge anders zu organisieren – und der Wechsel von VSS zu TFS ist eine großartige Gelegenheit, dies zu tun.

Soweit die ursprüngliche Frage:

Und:Diese Migration wird mit Sicherheit dazu führen, dass unsere Arbeitsgewohnheiten in irgendeiner Weise geändert werden müssen.Glauben Sie, dass diese Änderungen ein Problem für die Organisation darstellen könnten?Stellen Sie sich eine Gruppe von etwa 20 .net-Entwicklern auf einer einzigen Site vor

Ich würde sagen: Ja, Ihre Arbeitsgewohnheiten werden sich ändern, aber noch viel mehr zum Besseren.

  1. Sie sollten keine „Check-out“-Sperren und „Get-Latest on Check-out“ verwenden.
  2. Sie können jetzt effektiv verzweigen und zusammenführen
  3. Sie verfügen nun über „Änderungssätze“. Alle gleichzeitig eingecheckten Dateien werden gruppiert.Dadurch wird die Verfolgung historischer Änderungen wesentlich einfacher – aber was noch wichtiger ist: Rollbacks sind viel einfacher (d. h. alle gleichzeitig eingecheckten Dateien finden und ein Rollback durchführen).
  4. Einchecken mit Arbeitselementen verknüpfen.Übersehen Sie nicht die Arbeitselemente!Der größte Fehler, den Sie machen können, besteht darin, TFS nur als VSS-Ersatz zu verwenden.Die Build- und Projektmanagementfunktionen sind ausgezeichnet – Sie haben dafür bezahlt – NUTZEN SIE SIE!

Was Einzelheiten dazu angeht, wie sich Ihre Erfahrung ändern wird, sagte ein anderer ehemaliger Kollege von mir (und Team System MVP), Steve St.Jean hat einen ausführlichen Artikel über die Unterschiede geschrieben: Von VSS bis TFS

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top