Migrieren von Visual SourceSafe

Artikel
08/10/2011

Sie können das VSSConverter-Befehlszeilentool in Team Foundation verwenden, um Projekte, Dateien, Versionsverlauf, Bezeichnungen und Benutzerinformationen von der Visual SourceSafe-Datenbank auf den Server für Team Foundation-Versionskontrolle zu migrieren. Dieses Tool ist in Visual Studio Team Foundation Server enthalten.

Weitere Informationen zu Visual SourceSafe finden Sie auf der folgenden Seite der Microsoft-Website: Quellcodeverwaltung für Visual Studio.

So migrieren Sie Daten aus der Visual SourceSafe-Datenbank

**Verstehen Sie Hauptkonzepte. ** Bevor Sie die Daten von der Datenbank Visual SourceSafe zum Server für Team Foundation-Versionskontrolle migrieren, sollten Sie einige Hauptkonzepte verstehen. Team Foundation und Visual SourceSafe haben bedeutende funktionale Unterschiede. Als Ergebnis muss VSSConverter bestimmte Arten von Daten ändern, wenn sie migriert werden.

Weitere Informationen finden Sie weiter unten in diesem Thema unter Wie VSSConverter die Daten konvertiert.
**Sicherstellen, dass Sie über die erforderlichen Berechtigungen verfügen. **Um die Prozeduren in diesem Thema auszuführen, müssen Sie mehrere Typen von Berechtigungen haben. Weitere Informationen finden Sie unter Erforderliche Berechtigungen weiter unten in diesem Thema.
**Planen und Vorbereiten des Migrationsprozesses. **Bevor Sie den Migrationsvorgang starten, können Sie ernste Probleme für sich und das Team vermeiden, indem Sie Planungen und Vorbereitungen durchführen. Weitere Informationen finden Sie weiter unten in diesem Thema unter Planen und Vorbereiten des Migrationsprozesses.
**Analysieren der Daten. ** Bevor Sie die Daten von Visual SourceSafe nach Team Foundation-Versionskontrolle migrieren, müssen Sie zuerst die Analysefunktion des Visual SourceSafe-Konverters verwenden, um zu ermitteln, ob sich Probleme in den Daten auf das Ergebnis der Migration auswirken. Dieser Prozess generiert auch eine Benutzerzuordnungsdatei, die erforderlich ist, um die Daten zu migrieren. Weitere Informationen finden Sie unter Analysieren der Daten weiter unten in diesem Thema.
**Migrieren der Daten. **Nachdem Sie die Analysefunktion ausgeführt haben, sind Sie fast bereit, die Daten zu migrieren. Um die Daten zu migrieren, müssen Sie angeben, wie Benutzernamen migriert werden, eine Migrationseinstellungsdatei erstellen und dann den Migrationsbefehl ausführen. Weitere Informationen finden Sie unter Migrieren der Daten weiter unten in diesem Thema.
**Überprüfen der Migration und Beheben von Problemen. **Nachdem das Migrieren abgeschlossen wurde, sollten Sie die folgenden Schritte ausführen:
- Überprüfen Sie den Bericht, der von der Migrationsfunktion generiert wurde.
- Überprüfen Sie die Daten auf dem Server für Team Foundation-Versionskontrolle, um sicherzustellen, dass die Daten von der Datenbank Visual SourceSafe ordnungsgemäß migriert wurden.
Nachdem Sie diese Schritte ausgeführt haben, müssen Sie möglicherweise Probleme beheben. Weitere Informationen finden Sie unter Überprüfen der Migration und Beheben von Problemen weiter unten in diesem Thema.

Erforderliche Berechtigungen

Zum Ausführen der Verfahren in diesem Thema müssen Sie die folgenden Berechtigungen haben:

In der Datenbank Visual SourceSafe, die die Daten enthält, die Sie migrieren möchten, müssen Sie das Kennwort des Kontos Admin kennen.
Auf dem Migrationscomputer (der Computer, auf dem Visual Studio installiert ist) müssen Sie Mitglied der Gruppe Administratoren sein.
Auf der Datenbank, die VSSConverter verwendet, müssen Sie die Berechtigung "Datenbank erstellen" haben. Weitere Informationen finden Sie unter Bereitstellen einer Datenbank zur Verwendung durch VSSConverter weiter unten in diesem Thema.
Auf der Anwendungsstufe für Team Foundation müssen Sie Mitglied der Sicherheitsgruppe Team Foundation-Administratoren sein. Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

Planen und Vorbereiten des Migrationsvorgangs

Bevor Sie den Migrationsvorgang starten, können Sie ernste Probleme für sich und das Team vermeiden, indem Sie Planungen und Vorbereitungen durchführen.

Erwägen von Optionen zum Reduzieren der erforderlichen Zeit

Der Konverter bietet Migrationsoptionen, mit denen Sie die zum Migrieren benötigte Zeit minimieren können. Dabei wird so vorgegangen, dass entweder der Migrationszeitraum verkürzt wird oder die Teams während der Migration mit der Versionskontrolle arbeiten können. Sie müssen selbst genau einschätzen, welche der folgenden Migrationsoptionen am besten für Ihr Team geeignet ist:

Migrieren ausgewählter Projekte: Statt die ganze Visual SourceSafe-Datenbank gleichzeitig zu migrieren, können Sie ausgewählte Projekte zu anderen Zeiten migrieren. Weitere Informationen finden Sie weiter unten in diesem Thema im <ProjectMap>-Abschnitt.
Abschneiden einiger Verlaufsdaten: Sie können die Archivfunktion von Visual SourceSafe verwenden, um den partiellen Verlauf zu migrieren. Verwenden Sie diese Option, wenn Sie keinen alten Verlauf migrieren möchten. Bei Verwendung dieses Features wird der Versionsverlauf für Dateien und Ordner vor einem bestimmten Datum entfernt. Weitere Informationen finden Sie unter Verkleinern des Verlaufs von Elementen weiter unten in diesem Thema.

Planen der Migration mit dem Team

Versuchen Sie, die Migration zu planen, wenn Benutzer keinen Zugriff auf die Datenbank Visual SourceSafe benötigen, die Sie migrieren. Möglicherweise möchten Sie mehr Zeit aufwenden, um die Daten vorzubereiten und zu migrieren, wenn Sie viele Daten oder ein großes Team haben, oder wenn Sie lange an den Projekten gearbeitet haben.

Wichtig

Informieren Sie die Teammitglieder, wenn der Migrationsvorgang stattfindet, und raten Sie ihnen, alle Dateien einzuchecken, bevor der Prozess beginnt.

Kopieren und Vorbereiten der Visual SourceSafe-Datenbank

Kopieren und bereiten Sie die Datenbank Visual SourceSafe vor, indem Sie folgende Schritte ausführen:

Checken Sie Dateien ein. Idealerweise sollten alle Dateien in der Datenbank Visual SourceSafe eingecheckt werden. Sie sollten zumindest versuchen, möglichst viele Dateien einzuchecken.
Entfernen des Zugriffs auf die Visual SourceSafe-Projekte. Stellen Sie sicher, dass Sie die einzige Person sind, die Zugriff auf die Visual SourceSafe-Projekte hat, die Sie migrieren.
Kopieren der Datenbank. Befolgen Sie die Anweisungen, die auf der folgenden Seite der Microsoft-Website bereitgestellt werden: Sichern einer Visual SourceSafe-Datenbank.
Aktualisieren der Kopie der Datenbank. Wenn die Datenbank Visual SourceSafe älter als Visual SourceSafe 6.0 ist, aktualisieren Sie sie auf Visual SourceSafe 2005 mit dem Visual SourceSafe DDUPD-Hilfsprogramm. Weitere Informationen finden Sie im folgenden Thema auf der Microsoft-Website: DDUPD-Hilfsprogramm.
(Optional) Verkleinern des Verlaufs von Elementen. Weitere Informationen finden Sie unter Verkleinern des Verlaufs von Elementen weiter unten in diesem Thema.
Überprüfung auf und Beheben von Datenintegritätsproblemen in der Kopie der Datenbank. Verwenden Sie das Visual SourceSafe ANALYZE-Hilfsprogramm, um Datenintegritätsprobleme in der Datenbank zu suchen und zu beheben. Weitere Informationen zum Verwenden dieses Tools finden Sie auf den folgenden Seiten der Microsoft-Website: ANALYZE-Hilfsprogramm und Erkennen und Korrigieren von Datenbankbeschädigungsfehlern in Visual SourceSafe.

Verkleinern des Verlaufs von Elementen

Wenn Sie nicht den ganzen Verlauf migrieren möchten, der in Visual SourceSafe gespeichert ist, können Sie auch nur den Verlauf nach einem bestimmten Datum mit der Archivfunktion in Visual SourceSafe migrieren.

Warnung

Durch die Verwendung dieser Methode wird der Versionsverlauf permanent aus der Datenbank Visual SourceSafe entfernt. Stellen Sie daher sicher, dass Sie diese Prozedur auf einer Kopie der Datenbank Visual SourceSafe statt auf der gerade verwendeten Datenbank ausführen.

Um den Verlauf der Elemente in Visual SourceSafe zu verkürzen, verwenden Sie die Archivfunktionalität in Visual SourceSafe. Sie können den Zeitstempel angeben, vor dem Sie den Verlauf mithilfe einer der folgenden Werte verkürzen möchten:

Bezeichnung
Version eines Ordners
Datum

Weitere Informationen zum Archivieren in Visual SourceSafe finden Sie unter Visual SourceSafe-Archivdatenbanken.

Tipp

Die Visual SourceSafe-Archivfunktion hat eine Einschränkung von 2 Gigabyte (GB) für die Größe der Archivdatei. Wenn ein Fehler während des Prozesses auftritt, versuchen Sie, kleinere Projekte getrennt voneinander zu archivieren.

Vorbereiten des Migrationscomputers

Bereiten Sie den Migrationscomputer vor, indem Sie folgende Schritte ausführen:

Stellen Sie sicher, dass der Computer über genügend freien Speicherplatz zum Abschließen des Migrationsvorgangs verfügt. Rechnen Sie zum Schätzen des erforderlichen Speicherplatzes die folgenden Elemente zusammen:
- 5 GB Speicherplatz, der für VSSConverter verfügbar ist, um temporäre Dateien zu erstellen und Protokolldateien zu generieren.
- Speicherplatz, der der doppelten Größe der Projekte in der Datenbank Visual SourceSafe entspricht, die Sie migrieren.
- Speicherplatz, der ausreicht, um die Anwendungen zu installieren, die in den folgenden Schritten beschrieben werden.
Installieren Sie Visual Studio auf dem Migrationscomputer.

Wichtig

VSSConverter erfordert eine Datenbank (entweder SQL Server Express oder SQL Server), um zu funktionieren. Wenn Sie Visual Studio installieren, wird standardmäßig SQL Server Express installiert, und Ihnen wird die Berechtigung gewährt, die zum Funktionieren von VSSConverter erforderlich ist. Weitere Informationen finden Sie unter Bereitstellen einer Datenbank zur Verwendung durch VSSConverter weiter unten in diesem Thema.
Installieren Sie Visual SourceSafe 2005 auf dem Migrationscomputer.
Installieren Sie das Update, das dem Microsoft Knowledge Base-Artikel 950185 zugeordnet ist. Sie können diese Software von der folgenden Seite auf der Microsoft-Website erhalten: KB950185 - VSS Required QFE for Orcas SP1 VSSConverter.
Stellen Sie sicher, dass Sie die Schritte unter Kopieren und Vorbereiten der Visual SourceSafe-Datenbank ausgeführt haben.
Kopieren Sie die Datenbank Visual SourceSafe in einen Ordner auf dem Migrationscomputer.

Warnung

Wenn Sie Dateifreigabe verwenden, um den Zugriff auf die Daten in der Datenbank Visual SourceSafe durch den Migrationscomputer zu ermöglichen, statt die Datenbank zu kopieren, müssen Sie Lese- und Änderungsrechte für das Konto bereitstellen, das Sie zum Anmelden an den Migrationscomputer verwenden. Dieser Ansatz wird nicht empfohlen, da er möglicherweise den Migrationsvorgang verlängert.

Wichtig

Unabhängig davon, wie Sie den Migrationscomputer eingerichtet haben, um auf die Datenbank Visual SourceSafe zuzugreifen, stellen Sie sicher, dass Sie den Migrationsvorgang auf einer Kopie der Datenbank und nicht auf der gerade verwendeten Datenbank ausführen. Dieser Ansatz hilft, die Daten zu schützen.

Bereitstellen einer Datenbank für die Verwendung durch VSSConverter

VSSConverter erfordert eine Datenbank (entweder SQL Server Express oder SQL Server), um zu funktionieren. Wenn Sie Visual Studio installieren, wird standardmäßig SQL Server Express installiert. Wenn Sie sich entscheiden, diese Option bei der Installation von Visual Studio zu deaktivieren, müssen Sie später SQL Server Express manuell installieren oder SQL Server als Datenbank verwenden.

Unabhängig davon, welche Datenbank Sie verwenden, müssen Sie über die Berechtigung "Datenbank erstellen" verfügen. Für SQL Server Express wird Ihnen diese Berechtigung automatisch gewährt, wenn Sie es zusammen mit Visual Studio installieren.

Wenn Sie SQL Server statt SQL Server Expresses verwenden möchten, müssen Sie die Einstellungsdatei ändern. Weitere Informationen finden Sie unter <SQL>-Element weiter unten in diesem Thema.

Vorbereiten der Instanz von Team Foundation Server

Bereiten Sie den Migrationscomputer vor, indem Sie folgende Schritte ausführen:

Stellen Sie sicher, dass auf der Datenebene für Team Foundation genug Speicherplatz verfügbar ist. Sie benötigen wahrscheinlich ungefähr zweimal die Datengröße der Projekte in der Visual SourceSafe-Datenbank, die Sie migrieren.

Diese Anforderung ist möglicherweise abhängig von den folgenden Faktoren höher oder niedriger:
- Die Größe der zu migrierenden Visual SourceSafe-Datenbank
- Die Anzahl der zu migrierenden Aktionen.
Die Migrationsfunktion erfordert, dass die Teamprojektsammlungen und die Teamprojekte bereits auf dem Server für Team Foundation-Versionskontrolle vorhanden sind, bevor der Migrationsvorgang starten kann. Wenn Sie die Teamprojektsammlung oder das Teamprojekt, in das Sie die Visual SourceSafe-Daten migrieren möchten, noch nicht haben, führen Sie einen oder beide der folgenden Schritte aus:
- Erstellen Sie eine Teamprojektsammlung, in die Sie die Daten aus der Visual SourceSafe-Datenbank migrieren möchten. Weitere Informationen finden Sie unter Erstellen einer Teamprojektsammlung.
- Erstellen Sie mindestens ein Teamprojekt, in das Sie die Daten aus der Visual SourceSafe-Datenbank migrieren möchten. Weitere Informationen finden Sie unter Erstellen eines Teamprojekts.

Analysieren der Daten

Bevor Sie die Daten von Visual SourceSafe nach Team Foundation-Versionskontrolle migrieren, sollten Sie zuerst die Analysefunktion des Visual SourceSafe-Konverters verwenden, um zu ermitteln, ob sich Probleme in den Daten auf das Ergebnis der Migration auswirken. Diese Funktion generiert auch eine Benutzerzuordnungsdatei, die die Migrationsfunktion zum Migrieren der Daten verwendet.

Erstellen einer Analyseeinstellungsdatei

Um die Analysefunktion Analyse zu verwenden, müssen Sie eine Einstellungsdatei erstellen. In dieser Datei geben Sie den Pfad der Visual SourceSafe-Datenbank, die Sie migrieren, und die Ordner an, die Sie migrieren möchten.

Der folgende XML-Code ist ein Beispiel für eine Analyseeinstellungsdatei.

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
     <Source name="VSS">
          <VSSDatabase name="c:\ourvss"></VSSDatabase>
          <UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
     </Source>
     <ProjectMap>
          <Project Source="$/Core"></Project>
          <Project Source="$/ProjectA"></Project>
          <Project Source="$/ProjectB"></Project>
     </ProjectMap>
</ConverterSpecificSetting>
<Settings>
     <Output file="c:\ourvss\migrate\logs\ContosoVSSAnalyze.xml"></Output>
</Settings>
</SourceControlConverter>

Sie können das vorherige Beispiel kopieren, es in eine eigene Einstellungsdatei einfügen und dann ändern. Die folgenden Informationen können Ihnen helfen, das Beispiel anzupassen, um Ihre Anforderungen zu erfüllen.

<?xml encoding>-Attribut

Das <?xml encoding>-Attribut muss zur Codierung passen, die in der Einstellungsdatei verwendet wird. Wenn die Datei beispielsweise als Unicode gespeichert wird, lautet das <?xml encoding>-Tag folgendermaßen:

<?xml version="1.0" encoding="unicode">

<VSSDatabase name>-Attribut

Geben Sie im <VSSDatabase name>-Attribut den Pfad des Ordners an, der die Datei srcsafe.ini für die Kopie der Visual SourceSafe-Datenbank, die Sie migrieren, enthält. Der folgende Code ist ein Beispiel.

<Source name="VSS">
   ...
   <VSSDatabase name="c:\ourvss"></VSSDatabase>
   ...
</Source>

Der Pfad darf die Zeichenfolge srcsafe.ini nicht enthalten. Das folgende <VSSDatabase name>-Attribut ist z. B. falsch und bewirkt, dass der VSSConverter-Befehl fehlschlägt:

<Source name="VSS">
   ...
   <VSSDatabase name="c:\ourvss\srcsafe.ini"></VSSDatabase>
   ...
</Source>

<UserMap name>-Attribut

Die Analysefunktion erfasst und kompiliert Daten zu den Visual SourceSafe-Benutzern und speichert sie in einer XML-Datei. Optional können Sie den Pfad und den Namen der Datei angeben, in der Sie diese Daten im <UserMap name>-Attribut speichern möchten. Wenn Sie dieses Attribut nicht angeben, erstellt die Analysefunktion eine Datei mit dem Namen UserMap.xml und legt sie im aktuellen Verzeichnis ab.

<ProjectMap>-Abschnitt

Geben Sie im <ProjectMap>-Abschnitt den Pfad jedes Visual SourceSafe-Projekts an, das Sie im Source-Attribut eines <Project>-Elements migrieren möchten.

Um alle Daten in der Visual SourceSafe-Datenbank zu migrieren, passen Sie den <ProjectMap>-Abschnitt auf folgendes Beispiel an:

<ProjectMap>
   <Project From="$/"></Project>
</ProjectMap>

Statt die ganze Visual SourceSafe-Datenbank gleichzeitig zu migrieren, können Sie ausgewählte Projekte zu anderen Zeiten migrieren. Diese Option kann dazu beitragen, dass Teams während der Migration nicht blockiert werden, wenn Sie viele Daten migrieren.

Die Pfade in den Quellattributen dürfen sich nicht überschneiden. Der folgende <ProjectMap>-Abschnitt ist beispielsweise ungültig:

<ProjectMap>
   <Project Source="$/ProjectA"></Project>
   <Project Source="$/ProjectA/Controller"></Project>
</ProjectMap>

<Output file>-Attribut

Im <Settings>-Abschnitt können Sie im <Output file>-Attribut den Pfad und den Namen der Datei angeben, in der der Analysebericht geschrieben werden soll. Wenn Sie dieses Attribut nicht angeben, schreibt der Konverter den Bericht in eine Datei mit dem Namen VSSAnalysisReport.xml und legt sie im aktuellen Verzeichnis ab.

<SQL>-Element

Um den Konverter anzuweisen, SQL Server statt SQL Server Express zu verwenden, können Sie ein <SQL>-Element zum <Source>-Abschnitt der Migrationseinstellungsdatei hinzufügen. Dieses Element verwendet die folgende Syntax: <SQL Server="SQL_Server_name"></SQL>.

Das folgende <SQL>-Element gibt beispielsweise an, dass der Server "ContosoSQLServer" ist:

<Source name="VSS">
   ...
   <SQL Server="ContosoSQLServer"></SQL>
   ...
</Source>

Ausführen des Analysebefehls

So analysieren Sie ein Projekt mit dem Konverter

Klicken Sie auf Start, zeigen Sie auf Alle Programme, zeigen Sie auf Microsoft Visual Studio 2010, zeigen Sie auf Visual Studio-Tools klicken Sie mit der rechten Maustaste auf Visual Studio 10.0-Eingabeaufforderung, und klicken Sie dann auf Als Administrator ausführen.

Wenn das Dialogfeld Benutzerkontensteuerung angezeigt wird, klicken Sie auf Weiter.
Geben Sie die folgende Befehlszeile ein:

VSSConverter Analyze settings.xml

Ersetzen Sie settings.xml durch den Pfad und den Namen der Analyseeinstellungsdatei, die Sie erstellt haben.
Geben Sie das Administratorkennwort für Visual SourceSafe ein, wenn Sie dazu aufgefordert werden.

VSSConverter zeigt den laufenden Status an, wenn die Analysefunktion fortschreitet. Wenn der Prozess abgeschlossen wird, generiert die Analysefunktion einen Bericht und eine Benutzerzuordnungsdatei.

Überprüfen und Beheben von Problemen, die von der Analysefunktion gefunden wurden

Der Analysebericht enthält Informationen zu Problemen in der Visual SourceSafe-Datenbank, die möglicherweise während des Migrationsvorgangs Probleme verursachen. Versuchen Sie, möglichst viele dieser Probleme zu lösen, um spätere Probleme beim Migrationsvorgang zu minimieren, wie im nächsten Abschnitt beschrieben.

Einige Dateien werden ausgecheckt

Im Bericht werden Dateien aufgelistet, die gerade ausgecheckt werden. Der Migrationsvorgang speichert keine Auscheckinformationen. Idealerweise sollten alle Dateien in der Visual SourceSafe-Datenbank eingecheckt werden. Sie sollten zumindest versuchen, möglichst viele Dateien einzuchecken.

Einige Elemente weisen Datenintegritätsprobleme auf

Im Bericht werden Elemente aufgelistet, deren Datenintegrität beeinträchtigt wurde. Diese Elemente werden nicht migriert. Das Visual SourceSafe ANALYZE-Hilfsprogramm ist möglicherweise in der Lage, diese Probleme zu beheben. Weitere Informationen finden Sie auf den folgenden Seiten der Microsoft-Website: ANALYZE-Hilfsprogramm und Erkennen und Korrigieren von Datenbankbeschädigungsfehlern in Visual SourceSafe.

Einige Ordner in zugeordneten Projekten enthalten einen Verlauf, der nicht im < ProjectMap >-Abschnitt enthalten ist

Wenn ein Ordner in einer Visual SourceSafe-Datenbank von einem Projekt in ein anderes verschoben wird, ist der Verlauf dieses Ordners im ursprünglichen und im aktuellen Projekt enthalten. Um so einen Ordner mit dem gesamten Verlauf zu migrieren, müssen Sie das ursprüngliche und das aktuelle Projekt migrieren.

Sie migrieren z. B. das Visual SourceSafe-Projekt Projekt2. Dieses Projekt enthält den Ordner $/Projekt2/FunktionA, der an einem Punkt seines Verlaufs aus Projekt1 verschoben wurde.

Wenn der <ProjectMap>-Abschnitt Folgendes enthält …	Beispiel ...	Dann ...
Beide Projekte.	`<ProjectMap> <Project Source="$/Project1"></Project> <Project Source="$/Project2"></Project> </ProjectMap>`	Der Ordner wird mit seinem vollständigen Verlauf migriert.
Das Projekt, das ursprünglich den Ordner aber nicht das Projekt enthalten hat, das ihn gerade enthält.	`<ProjectMap> <Project Source="$/Project1"></Project> </ProjectMap>`	Der Ordner wird nicht migriert.
Das Projekt, das aktuell den Ordner aber nicht das Projekt enthält, in dem der Ordner ursprünglich enthalten war.	`<ProjectMap> <Project Source="$/Project2"></Project> </ProjectMap>`	Der Ordner wird mit seinem Verlauf ab dem Punkt migriert, an dem er ins aktuelle Projekt verschoben wurde. Der Verlauf, der aufgetreten ist, bevor der Ordner in das aktuelle Projekt verschoben wurde, wird nicht migriert.

Weitere Informationen zum <ProjectMap>-Abschnitt der Einstellungsdatei finden Sie unter <ProjectMap>-Abschnitt weiter oben in diesem Thema.

Einige Bezeichnungsnamen werden nicht von der Team Foundation-Versionskontrolle unterstützt

Die Berichtslisten-Bezeichnungsnamen, die sich beim Migrieren ändern, da sie Zeichen enthalten, die Team Foundation-Versionskontrolle nicht unterstützt.

Migrieren der Daten

Nachdem Sie die Analysefunktion ausgeführt haben, sind Sie fast bereit, die Daten zu migrieren. Bevor Sie den Befehl zum Migrieren ausführen, müssen Sie eine Migrationseinstellungsdatei erstellen. Optional können Sie angeben, wie Benutzernamen migriert werden sollen.

Angeben, wie Benutzernamen migriert werden sollen

Sie können steuern, wie Benutzerinformationen von Visual SourceSafe nach Team Foundation-Versionskontrolle migriert werden. Sie können ausdrücklich angeben, welchen Benutzernamen die Migrationsfunktion den einzelnen Changesets im Verlauf der einzelnen Elemente in Team Foundation-Versionskontrolle zuordnen soll. Dazu bearbeiten Sie die Benutzerzuordnungsdatei, die erstellt wurde, als Sie die Analysefunktion ausgeführt haben, wie früher in diesem Thema erklärt.

Die Benutzerzuordnungsdatei ist optional. Wenn Sie das <UserMap>-Element aus der Einstellungsdatei weglassen, wird jedes Changeset auf die folgende Weise erstellt:

Das Feld Benutzer wird auf den Namen des Kontos festgelegt, unter dem VSSConverter ausgeführt wird.
Der Name des Benutzers, der die Aktion in der Visual SourceSafe-Datenbank ausgeführt hat, wird im Feld Kommentar gespeichert.

Beispiel für eine Benutzerzuordnungsdatei

Wenn Sie die Analysefunktion ausführen, werden Daten zu den Visual SourceSafe-Benutzern kompiliert und in einer XML-Datei gespeichert. In dieser Datei wird jeder Visual SourceSafe-Benutzer, der je in den Visual SourceSafe-Projekten, die Sie migrieren, einen Versionskontrollvorgang ausgeführt hat, aufgelistet.

Im folgenden Beispiel wird eine Benutzerzuordnungsdatei gezeigt, die von der Analysefunktion des Visual SourceSafe-Konverters erstellt wurde.

<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
   <UserMap From="Admin" To=""></UserMap>
   <UserMap From="Guest" To=""></UserMap> 
   <UserMap From="Kim" To=""></UserMap>
   <UserMap From="Satomi" To=""></UserMap>
   <UserMap From="Mark" To=""></UserMap>
</UserMappings>

Sie können das To-Attribut von keinem, einigen oder allen UserMap-Elementen in der Benutzerzuordnungsdatei angeben. Sie können z. B. das vorherige Beispiel auf die folgende Weise ändern:

<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
   <UserMap From="Admin" To="NORTHAMERICA\KenM"></UserMap>
   <UserMap From="Guest" To="Test1"></UserMap> 
   <UserMap From="Kim" To="EUROPE\KimT"></UserMap>
   <UserMap From="Satomi" To="ASIA\SatomiH"></UserMap>
   <UserMap From="Mark" To=""></UserMap>
</UserMappings>

Beachten Sie, dass Guest im vorherigen Beispiel Test1 zugeordnet und keine Domäne angegeben wird. In diesen Fällen nimmt VSSConverter an, dass das Konto zur Standarddomäne gehört.

Wenn Sie kein <UserMap To>-Attribut angeben, wird jedes Changeset auf die folgende Weise erstellt:

Das Feld Benutzer wird auf den Namen des Kontos festgelegt, unter dem VSSConverter ausgeführt wurde.
Der Name des Benutzers, der die Aktion in der Visual SourceSafe-Datenbank ausgeführt hat, wird im Feld Kommentar gespeichert.
Wenn Sie ein <UserMap To>-Attribut angeben und der Wert ein gültiger Benutzer auf einem Server ist, der Team Foundation ausführt, wird das Feld Benutzer auf den Namen dieses Kontos festgelegt. Wenn der Wert kein gültiger Benutzer auf einem Server ist, der Team Foundation ausführt, zeigt VSSConverter einen Fehler an und beendet den Migrationsvorgang.

Erstellen einer Migrationseinstellungsdatei

Sie verwenden die Migrationseinstellungsdatei, um anzugeben, welche Visual SourceSafe-Daten Sie migrieren möchten, und um mehrere Aspekte der Migration zu steuern. Die einfachste Möglichkeit, diese Datei zu erstellen, besteht darin, die Datei zu kopieren, die Sie weiter oben in diesem Thema unter Erstellen einer Analyseeinstellungsdatei erstellt haben. Sie fügen der Datei dann weitere Daten hinzu, um sie durch die Migrationsfunktion verwendbar zu machen.

Das folgende Beispiel zeigt eine Migrationseinstellungsdatei.

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
     <Source name="VSS">
          <VSSDatabase name="c:\ourvss"></VSSDatabase>
          <UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
     </Source>
     <ProjectMap>
          <Project Source="$/Core" Destination="$/CoreTeamProject"></Project>
          <Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
          <Project Source="$/ProjectB" Destination="$/ClientTeamProject/ProjectB"></Project>
     </ProjectMap>
</ConverterSpecificSetting>
<Settings>
     <TeamFoundationServer name="My_Server" port="8080" protocol="http" collection="tfs/DefaultCollection"></TeamFoundationServer>
     <Output file="c:\ourvss\migrate\logs\ContosoVSSMigrate.xml"></Output>
</Settings>
</SourceControlConverter>

Die folgenden Informationen können Ihnen helfen, die Einstellungsdatei zu ändern, um anzugeben, wie die Migrationsfunktion die Daten migriert.

<Project Destination>-Attribut

Stellen Sie für jedes <Project>-Element im <ProjectMap>-Abschnitt der Einstellungsdatei ein Destination-Attribut bereit, um den Pfad des Speicherorts auf dem Server für Team Foundation-Versionskontrolle anzugeben, in den Sie den Inhalt des Projekts in der Visual SourceSafe-Datenbank (angegeben im Source-Attribut) migrieren möchten.

Sie möchten den Inhalt von ProjectA in der Visual SourceSafe-Datenbank z. B. in ProjectA im Stamm eines Teamprojekts mit dem Namen Client migrieren.

<ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
</ProjectMap>

Damit der Wert im Destination-Attribut gültig ist, müssen folgende Bedingungen erfüllt sein:

Das Teamprojekt im Destination-Attribut (im vorherigen Beispiel ist das Teamprojekt ClientTeamProject) muss sich bereits in der Teamprojektsammlung befinden, bevor Sie den Migrationsvorgang starten.
Wenn sich der Ordner im Destination-Attribut (im vorherigen Beispiel ist der Ordner ProjectA) bereits im Teamprojekt befindet, muss der Ordner leer sein.
Der Pfad im Destination-Attribut eines <Project>-Elements darf sich nicht mit dem Pfad im Destination-Attribut eines beliebigen anderen <Project>-Elements überschneiden. Der folgende <ProjectMap>-Abschnitt ist beispielsweise ungültig:
```
<ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProjectA/"></Project>
   <Project Source="$/ProjectB" Destination="$/ClientTeamProjectA/ProjectB"></Project>
</ProjectMap>
```

<TeamFoundationServer>-Tag

Fügen Sie im <Settings>-Abschnitt ein <TeamFoundationServer>-Tag hinzu, und geben Sie den Namen, Port, Protokoll und Pfad der Teamprojektsammlung auf dem Server an, der Team Foundation Server ausführt, in folgendem Format an:

<TeamFoundationServer name="ServerName" port="PortNumber" protocol="http" collection="path/collection name></TeamFoundationServer>

<Label migrate="false" />-Tag

Wenn die Visual SourceSafe-Datenbank viele Bezeichnungen enthält, die für viele Dateien übernommen werden, wird der Migrationsvorgang möglicherweise verlängert. Wenn das Team diese Daten nicht benötigt, können Sie VSSConverter konfigurieren, um Bezeichnungen zu ignorieren, indem das <Label migrate="false" />-Tag zum <Settings>-Abschnitt hinzugefügt wird.

<Output file>-Attribut

Im <Settings>-Abschnitt des <Output file>-Attributs können Sie den Pfad und die Datei angeben, in der der Migrationsbericht gespeichert werden soll. Wenn Sie das Attribut nicht einschließen, schreibt der Konverter den Bericht in eine Datei mit dem Namen VSSMigrationReport.xml und legt sie im aktuellen Verzeichnis ab.

Ausführen des Migrationsbefehls

So führen Sie den Migrationsbefehl aus

Klicken Sie auf Start, zeigen Sie auf Alle Programme, zeigen Sie auf Microsoft Visual Studio 2010, zeigen Sie auf Visual Studio-Tools klicken Sie mit der rechten Maustaste auf Visual Studio 10.0-Eingabeaufforderung, und klicken Sie dann auf Als Administrator ausführen.

Wenn das Dialogfeld Benutzerkontensteuerung angezeigt wird, klicken Sie auf Weiter.
Geben Sie an der Eingabeaufforderung die folgende Befehlszeile ein:

VSSConverter Migrate settings.xml

Ersetzen Sie settings.xml durch den Pfad und den Namen der Migrationseinstellungsdatei, die Sie erstellt haben.

Die Migrationsfunktion zeigt jedes Projekt an, das Sie aus der Visual SourceSafe-Datenbank migrieren, und jedem Ordner, in den die Daten auf dem Server für Team Foundation-Versionskontrolle migriert werden.
Wenn Sie aufgefordert werden, drücken Sie Y, um die Migration zu bestätigen.
Wenn Sie aufgefordert werden, geben Sie das Kennwort des Benutzers ein, der die Visual SourceSafe-Datenbank verwaltet.

Während des Prozesses zeigt die Migrationsfunktion den aktuellen Status im Eingabeaufforderungsfenster an.

Fortsetzen des Prozesses mithilfe der inkrementellen Migration

Wenn der Migrationsvorgang aus irgendeinem Grund unterbrochen wird, können Sie den Prozess als inkrementelle Migration von dem Punkt aus fortsetzen, an dem der Prozess beendet wurde. Eine inkrementelle Migration kann nützlich sein, wenn der Migrationsvorgang wegen eines Fehlers oder aufgrund von Netzwerkproblemen fehlgeschlagen ist. Während der inkrementellen Migration migriert der Konverter nur die Daten, die nicht in vorherigen Sitzungen migriert wurden.

Um eine inkrementelle Migration zu starten, führen Sie die Schritte unter Ausführen des Migrationsbefehls aus. Wenn die Migrationsfunktion fragt, ob Sie eine inkrementelle Migration ausführen möchten, drücken Sie Y.

Einschränkungen einer inkrementellen Migration

Eine inkrementelle Migration ist nur erfolgreich, wenn Sie die folgenden Einschränkungen einhalten:

In der Visual SourceSafe-Datenbank dürfen Sie keine Zerstörungs-, Säuberungs-, Archivierungs oder Wiederherstellungsaktivitäten ausführen.
Sie dürfen den <ProjectMap>-Abschnitt der Migrationseinstellungsdatei nicht ändern.
Auf dem Server für Team Foundation-Versionskontrolle dürfen Sie keine Ordner (oder Inhalte in den Ordnern) ändern, die im <ProjectMap> -Abschnitt der Migrationseinstellungsdatei angegeben werden.

Überprüfen von Migration und Beheben von Problemen

Nachdem die Migrationsfunktion abgeschlossen wurde, sollten Sie die folgenden Schritte ausführen:

Überprüfen Sie den Bericht, der von der Migrationsfunktion generiert wurde.
Überprüfen Sie die Daten auf dem Server für Team Foundation-Versionskontrolle, um sicherzustellen, dass die Daten ordnungsgemäß migriert wurden.

Nachdem Sie diese Schritte ausgeführt haben, müssen Sie möglicherweise Probleme beheben.

So lösen Sie das Problem des Überschreitens der Speichergrenze für SQL Server Express

VSSConverter speichert standardmäßig temporäre Metadaten mithilfe von SQL Server Express. Diese Metadaten erfordern in der Regel einen kleinen Prozentsatz der Gesamtgröße der Daten, die Sie migrieren. Im unwahrscheinlichen Fall, dass die Migration fehlschlägt, da die 4-GB-Grenze von SQL Server Express erreicht wird, können Sie eine Einstellung anwenden, die den Konverter anweist, stattdessen eine SQL Server-Bereitstellung zu verwenden. Weitere Informationen finden Sie unter <SQL>-Element weiter oben in diesem Thema.

Konvertieren von Dateien im MS-DOS-kompatiblen Kurznamenformat (8.3) (TF227014)

Team Foundation-Versionskontrolle lässt keine Dateinamen zu, die im MS-DOS-kompatiblen Kurznamenformat (8.3) vorliegen (z. B. abcdef~1.txt). Wenn Sie analysieren oder versuchen, Dateien zu migrieren, die einen solchen Namen haben, tritt ein TF227014-Fehler auf.

Um dieses Problem zu umgehen, können Sie vorübergehend eine Einstellung für die Anwendungsebene für Team Foundation anwenden, die es ermöglicht, Dateien mit solchen Namen zuzulassen. Hierzu müssen Sie Allow8Dot3Paths auf True in der Konfigurationsdatenbank für Team Foundation festlegen.

Wichtig

Um Probleme mit Clientcomputern zu vermeiden, die MS-DOS-kompatible Kurznamen unterstützen, sollten Sie nach dem Abschluss des Migrationsvorgangs Allow8Dot3Paths auf False festlegen, wie in der folgenden Prozedur beschrieben wird.

Um die folgende Prozedur auszuführen, muss Windows PowerShell auf dem Anwendungsebenenserver für Team Foundation aktiviert sein. Weitere Informationen finden Sie im folgenden Thema auf der Microsoft-Website: Skripting mit der Windows PowerShell.

Erforderliche Berechtigungen

Um diese Prozedur auszuführen, müssen Sie Mitglied der Gruppe Administratoren auf dem Anwendungsebenenserver für Team Foundation sein. Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

So migrieren Sie eine Visual SourceSafe-Datenbank, die Dateien enthält, die im MS-DOS-kompatiblen Kurznamenformat benannt sind

Melden Sie sich am Anwendungsebenenserver für Team Foundation an.
Erstellen Sie ein Windows PowerShell-Skript mit dem Namen Allow8Dot3Paths.
1. Kopieren Sie den Text in Allow8Dot3Paths PowerShell Script, und fügen Sie den Text in das Skript ein.
2. Ändern Sie ServerPath, um dem Pfad in der URL zu entsprechen, die Sie für die Verbindung mit Team Foundation Server verwenden. Standardmäßig ist der Serverpfad "tfs".
3. Ändern Sie CollectionName , um dem Namen der Teamprojektsammlung zu entsprechen, in die Sie die Daten migrieren (z. B. DefaultCollection).
  
  Das Endergebnis wäre z. B. die folgende Zeile im Skript:
```
$collectionBaseUrl = "https://localhost:8080/tfs/DefaultCollection/";
```
Führen Sie das Allow8Dot3Paths-Skript aus.
Verwenden Sie den Anwendungspool für Team Foundation wieder.
1. Klicken Sie auf Start, Verwaltung und Computerverwaltung.
2. Erweitern Sie im Navigationsbereich Dienste und Anwendungen.
3. Klicken Sie auf Internetinformationsdienste-Manager, erweitern Sie den lokalen Computer, und doppelklicken Sie auf Anwendungspools.
4. Klicken Sie mit der rechten Maustaste auf den Anwendungspool, und klicken Sie dann auf Wiederverwenden.
Führen Sie den Migrationsbefehl aus.

Weitere Informationen finden Sie unter Ausführen des Migrationsbefehls.
Ändern Sie das Allow8Dot3Paths Windows PowerShell-Skript, das Sie zuvor erstellt haben, indem Sie "true" durch "false" ersetzen.
Führen Sie das geänderte Allow8Dot3Paths-Skript aus.
Verwenden Sie den Anwendungspool für Team Foundation wieder.
1. Klicken Sie auf Start, Verwaltung und Computerverwaltung.
2. Erweitern Sie im Navigationsbereich Dienste und Anwendungen.
3. Klicken Sie auf Internetinformationsdienste-Manager, erweitern Sie den lokalen Computer, und doppelklicken Sie auf Anwendungspools.
4. Klicken Sie mit der rechten Maustaste auf den Anwendungspool, und klicken Sie dann auf Wiederverwenden.
Öffnen Sie Team Explorer, und stellen Sie eine Verbindung zur Teamprojektsammlung her, in die Sie die Daten migriert haben.
Benennen Sie im Quellcodeverwaltungs-Explorer alle Dateien um, die Namen im MS-DOS-kompatiblen Kurznamenformat (8.3) aufweisen.

Allow8Dot3Paths PowerShell-Skript

# Load client OM assembly.
[Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");

$collectionBaseUrl = "https://localhost:8080/ServerPath/CollectionName/";

$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);
$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);

# Set some version control settings in the collection hive.
$collectionHive.SetValue("/Service/VersionControl/Settings/Allow8Dot3Paths", "True");

# Display all version control settings as a table.
$collectionHive.ReadEntries("/Service/VersionControl/Settings/...") | ft -a

So konvertiert VSSConverter die Daten

Team Foundation und Visual SourceSafe haben bedeutende funktionale Unterschiede. Als Ergebnis muss VSSConverter bestimmte Arten von Daten ändern, wenn sie migriert werden.

Changesets

Eine Hauptfunktion von Team Foundation-Versionskontrolle besteht im Gruppieren von Änderungen an mehreren Dateien in eine einzige Einheit, wenn ein Benutzer einen Änderungssatz eincheckt. Diese einzelne Einheit wird als Changeset bezeichnet.

Visual SourceSafe hat keine Funktion, die Changesets entspricht. Während des Konvertierungsprozesses wird jeder Änderungssatz jedoch in ein Changeset gruppiert, solange die folgenden Bedingungen erfüllt sind:

Die Änderungen widersprechen einander nicht. Zum Beispiel dürfen sich zwei Aktionen nicht auf dieselbe Datei oder denselben Ordner auswirken.
Die Änderungen sind nacheinander innerhalb weniger Minuten aufgetreten .
Die Änderungen wurden vom gleichen Benutzer eingecheckt.
Die Änderungen weisen den gleichen Eincheckkommentar auf.

Weitere Informationen finden Sie unter Arbeiten mit Changesets.

Freigeben und Festhalten

In Visual SourceSafe können Sie eine Datei ordnerübergreifend freigeben. Änderungen, die Sie an einer freigegebenen Datei vornehmen, werden in den Ordnern repliziert, in denen die Datei freigegeben ist. Team Foundation-Versionskontrolle hat keine entsprechende Funktion. Während der Migration werden freigegebene Dateien im Visual SourceSafe-Projekt durch das Erstellen einer zusätzlichen unabhängigen Kopie des Elements auf dem Server für Team Foundation-Versionskontrolle migriert.

Team Foundation-Versionskontrolle hat keine Funktion, die der Festhaltefunktion in Visual SourceSafe entspricht. Während der Migration werden festgehaltene Elemente im Visual SourceSafe-Projekt auf dem Server für Team Foundation-Versionskontrolle in bezeichnete Elemente konvertiert. Weitere Informationen finden Sie im nächsten Abschnitt.

Weitere Informationen über Bezeichnungen in Team Foundation-Versionskontrolle finden Sie unter Verwenden von Bezeichnungen zum Erstellen einer Momentaufnahme der Dateien.

Verlaufsdaten

Alle Ereignisse im Verlauf eines Elements in der Visual SourceSafe-Datenbank werden als Changeset auf den Server für Team Foundation-Versionskontrolle übertragen. Nachdem der Migrationsvorgang abgeschlossen wurde, können Sie diese Daten im Verlaufsfenster anzeigen. Weitere Informationen finden Sie unter Verwenden des Fensters Versionsgeschichte.

Einige Änderungen an den Daten treten während der Migration auf.

Migrieren der Daten zum Benutzernamen und des Datums- und Zeitstempels

Da jeder Eintrag im Verlauf eines Elements in der Visual SourceSafe-Datenbank in ein Changeset auf dem Server für Team Foundation-Versionskontrolle migriert wird, treten die folgenden Änderungen auf:

Der Datums- und Zeitstempel auf dem Changeset wird auf das Datum und die Uhrzeit der Migration des Elements festgelegt.
Das ursprüngliche Datum und der Zeitstempel werden im Feld Kommentar des Changesets gespeichert.
Der Benutzername wird im Benutzerfeld oder im Kommentarfeld des Changesets gespeichert, je nach Ergebnis des Benutzerzuordnungsprozesses. Weitere Informationen finden Sie unter Angeben, wie Benutzernamen migriert werden sollen weiter oben in diesem Thema.

Konvertieren bestimmter Ereignistypen

Ereignisse, wie z. B. Bearbeiten, Umbenennen und Löschen, werden auf einfache Weise von der Visual SourceSafe-Datenbank in Changesets auf dem Server für Team Foundation-Versionskontrolle migriert. VSSConverter migriert jedoch einige Ereignisse auf unerwartete Weise, wie die folgende Tabelle zeigt.

Visual SourceSafe Ereignis	Migration nach Team Foundation
Hinzufügen einer Datei oder eines Ordners	Dieses Changeset ist das erste Ereignis im Verlauf jeder Datei und jedes Ordners, die bzw. der migriert wird. Anders als in Visual SourceSafe wird kein Ereignis für das übergeordnete Element der einzelnen untergeordneten Elemente protokolliert, das es enthält.
Verzweigen	Freigabe ist eine Vorbedingung der Verzweigung in Visual SourceSafe, aber Team Foundation-Versionskontrolle unterstützt das Freigeben nicht. Daher erstellt die Migration einer verzweigten Datei eine Kopie der Datei im Zielordner. Die freigegebenen Dateien in der Visual SourceSafe-Datenbank werden zu Team Foundation-Versionskontrolle migriert, indem die Version der Datei, die vorhanden war, als sie freigegeben wurde, kopiert und diese Kopie im Zielordner abgelegt wird. Danach wird jedes Changeset in beiden Kopien der Datei repliziert, bis das Verzweigungsereignis auftritt.
Bezeichnen einer Datei	In Team Foundation wenden Sie eine Bezeichnung auf die Version einer Datei oder eines Ordners an. In Visual SourceSafe können Sie eine Datei explizit oder implizit bezeichnen. Wenn eine Datei explizit in Visual SourceSafe bezeichnet wird, wird eine neue Version der Datei erstellt. Wenn Sie Dateien mit dieser Bezeichnung erhalten, rufen Sie den Inhalt der Datei ab, die der Version der Datei entspricht, die vorhanden war, als die Bezeichnung erstellt wurde. Um explizite Bezeichnungen zu migrieren, nimmt der Konverter die Bezeichnung, die der in Visual SourceSafe bezeichneten Version entspricht, und wendet sie auf die Version in Team Foundation an. Dabei wird allerdings keine neue Version erstellt. Wenn Sie eine Bezeichnung auf einen Ordner in Visual SourceSafe anwenden, wird die Bezeichnung implizit auf alle Dateien und Ordner in diesem Ordner angewendet, und der Konverter erstellt keine neuen Versionen. Bei impliziten Bezeichnungen führt der Konverter keine Aktionen aus, da die entsprechenden Versionen in Team Foundation bei der Migration von expliziten Bezeichnungen für den Ordner automatisch bezeichnet werden. Hinweis Wenn die Visual SourceSafe-Datenbank viele Bezeichnungen enthält, die für viele Dateien übernommen werden, wird der Migrationsvorgang möglicherweise verlängert.Wenn das Team diese Daten nicht benötigt, können Sie VSSConverter so konfigurieren, dass Bezeichnungen ignoriert werden.Weitere Informationen finden Sie weiter oben in diesem Thema unter <Label migrate="false" />.
Bezeichnen eines Ordners	Wenn Sie eine Bezeichnung auf einen Ordner anwenden, werden in Visual SourceSafe alle Dateien und Ordner in diesem Ordner implizit bezeichnet. Neue Versionen werden nicht erstellt. Bei der Migration dieser Ordner wendet der Konverter die Bezeichnung auf die entsprechende Version des Ordners in Team Foundation an. Dadurch wird die Bezeichnung automatisch auf die aktuellen Versionen der Dateien und Ordner innerhalb des bezeichneten Ordners angewendet. Hinweis Wenn die Visual SourceSafe-Datenbank viele Bezeichnungen enthält, die für viele Dateien übernommen werden, wird der Migrationsvorgang möglicherweise verlängert.Wenn das Team diese Daten nicht benötigt, können Sie VSSConverter so konfigurieren, dass Bezeichnungen ignoriert werden.Weitere Informationen finden Sie unter <Label migrate="false" />.
Verschieben eines Ordners	Durch das Ereignis zum Verschieben eines Ordners wird in Team Foundation eine neue Version des Ordners erstellt. VSSConverter migriert den vollständigen Verlauf von Elementen in verschobenen Ordnern nur dann, wenn Quell- und Zielordner gleichzeitig migriert werden. Weitere Informationen finden Sie unter Überprüfen und Beheben von Problemen, die von der Analysefunktion gefunden wurden. Hinweis Wenn das Ereignis zum Verschieben von Ordnern mit einem Wiederherstellungsereignis kombiniert wird, werden die Verlaufsdaten möglicherweise nicht ordnungsgemäß migriert.
Wiederherstellen	Verlaufsdaten, die vor einem Wiederherstellungsereignis auftreten, werden nicht migriert.
PIN und UNPIN	Team Foundation-Versionskontrolle unterstützt kein Festhalten. VSSConverter migriert eine festgehaltene Datei, indem zwei Bezeichnungen erstellt werden. Die PINNED_LATEST-Bezeichnung wird auf die festgehaltenen Versionen der festgehaltenen Dateien und auf die aktuelle Version der nicht festgehaltenen Dateien angewendet. Die PINNED-Bezeichnung wird nur auf die festgehaltenen Versionen der festgehaltenen Dateien angewendet. Nach der Migration ruft die PINNED_LATEST-Bezeichnung dieselben Dateien wie Letzte Version abrufen in Visual SourceSafe ab. Mit der PINNED_LATEST-Bezeichnung werden jedoch u. U. andere Dateien zurückgegeben, wenn nach dem Festhalten andere Ereignisse als das Einchecken eingetreten sind, z. B. das Umbenennen oder Löschen der Datei.
Freigabe	Team Foundation-Versionskontrolle unterstützt keine Freigabe. Freigegebene Dateien in der Visual SourceSafe-Datenbank werden zu Team Foundation-Versionskontrolle migriert, indem die Version der Datei, die vorhanden war, als sie freigegeben wurde, kopiert und diese Kopie im Zielordner abgelegt wird. Danach wird jedes Changeset in beiden Kopien der Datei repliziert.
Wiederherstellen einer Datei oder eines Ordners	Während der Migration von Wiederherstellungsereignissen für eine Datei oder einen Ordner wiederholt der Konverter das Ereignis, um eine neue Version der Datei und des Ordners in Team Foundation zu erstellen. VSSConverter erstellt ein Changeset, das die Datei oder den Ordnernamen, das Datum und die Uhrzeit der Wiederherstellung sowie den Benutzernamen einschließt.

Quellcodeverwaltungs-Bindungen

VSSConverter stellt Versionskontrollbindungen für jede Lösung wieder her.

Freigeben über

Migrieren von Visual SourceSafe

So migrieren Sie Daten aus der Visual SourceSafe-Datenbank

Erforderliche Berechtigungen

Planen und Vorbereiten des Migrationsvorgangs

Erwägen von Optionen zum Reduzieren der erforderlichen Zeit

Planen der Migration mit dem Team

Kopieren und Vorbereiten der Visual SourceSafe-Datenbank

Verkleinern des Verlaufs von Elementen

Vorbereiten des Migrationscomputers

Bereitstellen einer Datenbank für die Verwendung durch VSSConverter

Vorbereiten der Instanz von Team Foundation Server

Analysieren der Daten

Erstellen einer Analyseeinstellungsdatei

<?xml encoding>-Attribut

<VSSDatabase name>-Attribut

<UserMap name>-Attribut

<ProjectMap>-Abschnitt

<Output file>-Attribut

<SQL>-Element

Ausführen des Analysebefehls

So analysieren Sie ein Projekt mit dem Konverter

Überprüfen und Beheben von Problemen, die von der Analysefunktion gefunden wurden

Einige Dateien werden ausgecheckt

Einige Elemente weisen Datenintegritätsprobleme auf

Einige Ordner in zugeordneten Projekten enthalten einen Verlauf, der nicht im < ProjectMap >-Abschnitt enthalten ist

Einige Bezeichnungsnamen werden nicht von der Team Foundation-Versionskontrolle unterstützt

Migrieren der Daten

Angeben, wie Benutzernamen migriert werden sollen

Beispiel für eine Benutzerzuordnungsdatei

Erstellen einer Migrationseinstellungsdatei

<Project Destination>-Attribut

<TeamFoundationServer>-Tag

<Label migrate="false" />-Tag

<Output file>-Attribut

Ausführen des Migrationsbefehls

So führen Sie den Migrationsbefehl aus

Fortsetzen des Prozesses mithilfe der inkrementellen Migration

Überprüfen von Migration und Beheben von Problemen

So lösen Sie das Problem des Überschreitens der Speichergrenze für SQL Server Express

Konvertieren von Dateien im MS-DOS-kompatiblen Kurznamenformat (8.3) (TF227014)

So migrieren Sie eine Visual SourceSafe-Datenbank, die Dateien enthält, die im MS-DOS-kompatiblen Kurznamenformat benannt sind

Allow8Dot3Paths PowerShell-Skript

So konvertiert VSSConverter die Daten

Changesets

Freigeben und Festhalten

Verlaufsdaten

Migrieren der Daten zum Benutzernamen und des Datums- und Zeitstempels

Konvertieren bestimmter Ereignistypen

Quellcodeverwaltungs-Bindungen

Zusätzliche Ressourcen