Migrar do Visual SourceSafe

Artigo
08/01/2011

Você pode usar o Team Foundation VSSConverter ferramenta de linha de comando para migrar projetos, arquivos, histórico de versão, rótulos e as informações do usuário do seu Visual SourceSafe banco de dados ao servidor para Controle de versão do Team Foundation. Essa ferramenta está incluída no Visual Studio Team Foundation Server.

Para obter mais informações sobre Visual SourceSafe, consulte a seguinte página no site da Microsoft: Controle de origem para Visual Studio.

Para migrar dados de seu banco de dados do Visual SourceSafe

**Compreenda os conceitos principais. **Antes de migrar os dados da sua Visual SourceSafe banco de dados ao servidor para Controle de versão do Team Foundation, você deve compreender alguns conceitos importantes. Team Foundatione Visual SourceSafe têm diferenças funcionais significativos. Como resultado, o VSSConverter deve modificar certos tipos de dados como ele é migrado.

Para obter mais informações, consulte Como VSSConverter converte seus dados posteriormente neste tópico.
**Certifique-se de que você tenha as permissões necessárias. **Para executar os procedimentos neste tópico, você deve ter vários tipos de permissões. Para obter mais informações, consulte Permissões necessárias posteriormente neste tópico.
**Planejar e preparar para o processo de migração. **Antes de iniciar o processo de migração, você pode evitar sérios problemas para você e sua equipe, tirando as etapas para planejar e preparar. Para obter mais informações, consulte planejamento e preparação para o processo de migração posteriormente neste tópico.
**Analise seus dados. **Antes de migrar seus dados de Visual SourceSafe para Controle de versão do Team Foundation, primeiro você deve usar o recurso de análise da Visual SourceSafe Conversor para determinar se os problemas em seus dados afetará o resultado da migração. Esse processo também gera um arquivo de mapeamento de usuário é necessário para migrar seus dados. Para obter mais informações, consulte Analisar seus dados posteriormente neste tópico.
**Migre seus dados. **Depois de executar o recurso de Analyze, você está quase pronto para migrar seus dados. Para migrar seus dados, especificar como os nomes de usuário são migrados, criar um arquivo de configurações de migração e, em seguida, execute o comando de migração. Para obter mais informações, consulte Migrar seus dados posteriormente neste tópico.
**Verifique se a migração e resolver problemas. **Recurso após a migração foi concluída, você deve executar as seguintes etapas:
- Analise o relatório gerado pelo recurso de migração.
- Verifique os dados em seu servidor para Controle de versão do Team Foundation para certificar-se de que os dados da sua Visual SourceSafe banco de dados foi migrado corretamente.
Depois de executar essas etapas, talvez você precise solucionar problemas. Para obter mais informações, consulte de migração de verificar e resolver problemas posteriormente neste tópico.

Permissões necessárias

Para executar os procedimentos neste tópico, você deve ter as seguintes permissões:

No Visual SourceSafe banco de dados que contém os dados que você deseja migrar, você precisa saber a senha do Admin conta.
Na máquina de migração (a máquina onde Visual Studio está instalado), você deve ser um membro da administradores grupo.
No banco de dados que usa o VSSConverter, você deve ter "criar o banco de dados" permissão. Para obter mais informações, consulte fornecer VSSConverter para uso em um banco de dados posteriormente neste tópico.
Na camada do aplicativo para Team Foundation, você deve ser um membro da Os administradores do Team Foundation o grupo de segurança. For more information, see Permissões de Team Foundation Server.

Planejar e preparar para o processo de migração

Antes de começar o processo de migração, você pode evitar sérios problemas para você e sua equipe tomando atitudes para planejar e preparar.

Considere as opções para reduzir o tempo necessário

O conversor fornece opções de migração podem minimizar o tempo para migrar, reduzindo o tempo de migração ou permitindo que as equipes trabalhem no controle de versão durante a migração. Avalie quais a migração seguinte opções funcionam melhor para sua equipe:

Migrar os projetos selecionados: em vez de migrar toda a sua Visual SourceSafe banco de dados ao mesmo tempo, você pode migrar projetos selecionados em diferentes horários. Para obter mais informações, consulte <ProjectMap> Seção posteriormente neste tópico.
Truncar alguns dados históricos: Você pode usar o recurso de arquivamento de Visual SourceSafe para migrar histórico parcial. Use esta opção se você não estiver interessado em migrar histórico antigo. Usando esse recurso, você pode remover o histórico de versões de arquivos e pastas antes de uma data específica. Para obter mais informações, consulte truncar o histórico de itens posteriormente neste tópico.

Agendar a migração com sua equipe.

Tente agendar a migração quando usuários não precisam ter acesso para o Visual SourceSafe banco de dados que você está migrando. Você talvez queira permitir um tempo significativo preparar e migrar seus dados se você tiver grandes quantidades de dados, uma grande equipe, ou se você trabalhou nos projetos por um longo tempo.

Importante
Quando o processo de migração ocorrer e aconselhe-os a fazer check-in de todos os arquivos antes do processo começa, informe os membros da equipe.

Copiar e preparar o banco de dados do Visual SourceSafe

Copiar e preparar seu Visual SourceSafe banco de dados seguindo estas etapas:

**Fazer check-in de arquivos.**o ideal é que todos os arquivos no seu Visual SourceSafe banco de dados deve estar com check-in. Pelo menos tentar fazer check-in tantos arquivos quanto possível.
**Remover o acesso a projetos do Visual SourceSafe.**Certificar-se de que você está a única pessoa que possui acesso para o Visual SourceSafe os projetos que você está migrando.
Copie o banco de dados. Siga as instruções fornecidas na página a seguir no site da Microsoft: Como fazer backup de um banco de dados Visual SourceSafe.
**Atualizar a cópia do banco de dados.**Se seu Visual SourceSafe banco de dados é uma versão anterior de Visual SourceSafe 6.0, atualize-o para Visual SourceSafe 2005 usando o Visual SourceSafe DDUPD utility. Para obter mais informações, consulte o tópico a seguir no site da Microsoft: Utilitário DDUPD.
**(Opcional) Truncar o histórico de itens.**Para obter mais informações, consulte truncar o histórico de itens posteriormente neste tópico.
**Verificar e corrigir problemas de integridade de dados na cópia do banco de dados.**Uso de Visual SourceSafe o utilitário ANALYZE para localizar e corrigir problemas de integridade de dados no banco de dados. Para obter mais informações sobre como usar essa ferramenta, consulte as seguintes páginas no site da Microsoft: ANALISAR o utilitário e como detectar e corrigir erros de corrupção de banco de dados no Visual SourceSafe.

Truncar o histórico de itens

Se não quiser migrar todo o histórico que é armazenado em Visual SourceSafe, você pode migrar somente o histórico após uma data específica, usando o recurso de arquivamento em Visual SourceSafe.

Aviso

Uso deste método remove permanentemente o histórico de versões a partir do Visual SourceSafe banco de dados. Portanto, certifique-se de que você executar esse procedimento em uma cópia da Visual SourceSafe banco de dados em vez do banco de dados no serviço.

Truncar o histórico de seus itens em Visual SourceSafe, usar a funcionalidade de arquivamento em Visual SourceSafe. Você pode especificar o carimbo de hora antes da qual você deseja truncar o histórico, usando qualquer um dos seguintes valores:

Label
Versão de uma pasta
Date

Para obter mais informações sobre como arquivar em Visual SourceSafe, consulte Bancos de dados do Visual SourceSafe arquivamento.

Observação
O Visual SourceSafe o recurso de arquivamento possui uma limitação de 2 gigabytes (GB) no tamanho do arquivo morto. Se ocorrer um erro durante o processo, tente arquivar projetos menores separadamente.

Preparar o computador de migração

Prepare o computador de migração, seguindo estas etapas:

Certifique-se de que a máquina tem espaço em disco livre suficiente para concluir o processo de migração. Para estimar quanto espaço em disco é necessário, total de itens a seguir:
- 5 GB de espaço em disco disponível para o VSSConverter para criar arquivos temporários e gerar arquivos de log.
- Espaço é igual a duas vezes o tamanho dos projetos no disco do Visual SourceSafe banco de dados que você irá migrar.
- Espaço em disco suficiente instalar os aplicativos que estão descritos nas etapas a seguir.

Instalar Visual Studio na máquina de migração.

Importante
VSSConverter requer um banco de dados (ou SQL Server Express ou SQL Server) para a função. Por padrão, quando você instala o Visual Studio, SQL Server Express é instalado, e você receberá a permissão que é necessária para VSSConverter a função. Para obter mais informações, consulte fornecer VSSConverter para uso em um banco de dados posteriormente neste tópico.

Instalar Visual SourceSafe 2005 na máquina de migração.
Instale a atualização que está associada ao artigo 950185 da Base de Conhecimento Microsoft. Você pode obter esse software na seguinte página no site da Microsoft: KB950185 - VSS necessário QFE para VSSConverter do SP1 Orcas.
Certifique-se de que você seguiu as etapas na Copy e preparar O Visual SourceSafe Database.

Cópia de Visual SourceSafe banco de dados para uma pasta na máquina de migração.

Aviso

Se você usar o compartilhamento de arquivos para ativar a máquina de migração para acessar os dados de Visual SourceSafe banco de dados em vez de copiar o banco de dados, você deve fornecer a leitura e modificar o acesso à conta que você pode usar para fazer logon na máquina de migração. Essa abordagem não é recomendada porque pode prolongar o processo de migração.

Importante
Independentemente de como você configurar sua máquina de migração para acessar seu Visual SourceSafe banco de dados, certifique-se de que você execute o processo de migração de uma cópia do banco de dados e não o banco de dados no serviço. Essa abordagem ajuda a proteger seus dados.

Fornecer o VSSConverter usar em um banco de dados

VSSConverter requer um banco de dados (ou SQL Server Express ou SQL Server) para a função. Por padrão, quando você instala o Visual Studio, SQL Server Express é instalado. Se você optar por desmarcar esta opção quando você instala o Visual Studio, você deve instalar manualmente SQL Server Express mais tarde ou use SQL Server como o banco de dados.

Qualquer banco de dados que você usa, você deve ter "Criar banco de dados" permissão no banco de dados. Para SQL Server Express, essa permissão é concedida para você automaticamente se você instalá-lo junto com Visual Studio.

Se você quiser usar SQL Server em vez de SQL Server Express, você deve modificar o arquivo de configurações. Para obter mais informações, consulte <SQL> Elemento posteriormente neste tópico.

Preparar a sua instância do de Team Foundation Server

Prepare o computador de migração, seguindo estas etapas:

Certifique-se de que os dados de nível de Team Foundation tem espaço de armazenamento suficiente disponível. Você provavelmente precisará de cerca de duas vezes o tamanho dos dados dos projetos na Visual SourceSafe banco de dados que você está migrando.

Esse requisito pode ser maior ou menor dependendo dos seguintes fatores:
- O tamanho da Visual SourceSafe banco de dados em migração.
- O número de ações a serem migrados.
O recurso de migração requer que as coleções de projeto de equipe e os projetos de equipe já existirem no seu servidor para Controle de versão do Team Foundation antes do processo de migração pode iniciar. Se você ainda não tem a coleção de projeto de equipe ou o projeto de equipe, no qual você deseja migrar seu Visual SourceSafe dados, execute uma ou ambas as seguintes etapas:
- Criar uma coleção de projeto de equipe no qual você deseja migrar os dados da sua Visual SourceSafe banco de dados. Para obter mais informações, consulte Criar uma coleção de projeto de equipe.
- Criar um ou mais projetos de equipe, no qual você deseja migrar os dados da sua Visual SourceSafe banco de dados. Para obter mais informações, consulte Criar um projeto de equipe.

Analisar seus dados

Antes de migrar seus dados de Visual SourceSafe para Controle de versão do Team Foundation, primeiro, você deve usar o recurso de análise da Visual SourceSafe Conversor para determinar se os problemas em seus dados afetará o resultado da migração. Esse recurso também gera um arquivo de mapeamento de usuário usa o recurso de migração para migrar seus dados.

Criar um arquivo de configurações de análise

Para usar o recurso de Analyze, você deve criar um arquivo de configurações. Nesse arquivo, você pode especificar o caminho da Visual SourceSafe banco de dados que você irá migrar e as pastas que você deseja migrar.

O XML a seguir é um exemplo de um arquivo de configurações de análise.

<?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>

Você pode copiar o exemplo anterior, colá-lo em seu próprio arquivo de configurações e modificá-lo. As informações a seguir podem ajudá-lo a adaptar o exemplo para atender às suas necessidades.

<? xml codificação > atributo

O <?xml encoding> atributo deve coincidir com a codificação usada em seu arquivo de configurações. Por exemplo, se o arquivo é salvo como Unicode, o <?xml encoding> tag é como segue:

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

< nome do VSSDatabase > atributo

No <VSSDatabase name> de atributo, especifique o caminho da pasta que contém o srcsafe.ini o arquivo para a cópia do banco de dados deVisual SourceSafe que você está migrando. O código a seguir é um exemplo.

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

O caminho não deve conter a seqüência de caracteres srcsafe.ini. Por exemplo, o seguinte <VSSDatabase name> atributo está incorreto e fará com que o VSSConverter comando falha:

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

< nome do UserMap > atributo

O recurso de analisar a coleta e compila dados sobre sua Visual SourceSafe os usuários e as armazena em um arquivo XML. Opcionalmente, você pode especificar o caminho e o nome do arquivo onde você deseja que os dados armazenados na <UserMap name> atributo. Se você não especificar esse atributo, o recurso de Analyze cria um arquivo chamado UserMap.xml e a coloca no diretório atual.

<ProjectMap> seção

No <ProjectMap> seção, especifique o caminho de cada Visual SourceSafe o projeto que você deseja migrar na Source atributo de um <Project> item.

Para migrar todos os dados em seu Visual SourceSafe banco de dados, verifique o <ProjectMap> seção coincidir com o exemplo a seguir:

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

Em vez de concluir a migração Visual SourceSafe banco de dados ao mesmo tempo, você pode migrar projetos selecionados em diferentes horários. Esta opção pode ajudá-lo a evitar o bloqueio equipes durante a migração, se você tiver grandes quantidades de dados para migrar.

Os caminhos de atributos de origem não devem se sobrepor. Por exemplo, o seguinte <ProjectMap> seção não é válida:

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

< arquivo de saída > atributo

No <Settings> seção, o <Output file> atributo, você pode especificar o caminho e o nome do arquivo onde você deseja que o relatório de análise para serem gravados. Se você não especificar esse atributo, o conversor grava o relatório em um arquivo chamado VSSAnalysisReport.xml e a coloca no diretório atual.

<SQL> elemento

Para direcionar o conversor para usar SQL Server em vez de SQL Server Express, você pode adicionar um <SQL> elemento para o <Source> seção do seu arquivo de configurações de migração. Este elemento usa a seguinte sintaxe: <SQL Server="SQL_Server_name"></SQL>.

Por exemplo, o seguinte <SQL> elemento indica que o servidor é "contososqlserver":

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

Execute o comando Analyze

Para analisar um projeto usando o conversor

Clique em Iniciar, aponte para Todos os programas, aponte para 2010 do Microsoft Visual Studio, aponte para Visual Studio Tools, com o botão direito Prompt de comando de 10.0 Visual Studioe, em seguida, clique em Executar como administrador.

Se o O controle de conta de usuário caixa de diálogo exibida, clique em continuar.
Digite a seguinte linha de comando:

VSSConverter Analyze Settings. XML

Substitua Settings. XML com o caminho e o nome do arquivo de configurações de análise que você criou.
Quando solicitado, forneça a senha de administrador para Visual SourceSafe.

VSSConverter exibe o status de andamento como recurso prossegue Analyze. Quando o processo for concluído, o recurso de análise gera um relatório e um arquivo de mapeamento do usuário.

Analisar e resolver problemas encontrados pelo recurso Analyze

O relatório de análise fornece informações sobre problemas no seu Visual SourceSafe banco de dados que pode causar problemas durante o processo de migração. Tente resolver como muitos desses problemas possíveis para minimizar problemas com o processo de migração, conforme descrito na próxima seção.

Alguns arquivos estão com Check-Out.

O relatório lista os arquivos atualmente check-out. O processo de migração não preserva informações de check-out. O ideal é que todos os arquivos no seu Visual SourceSafe banco de dados deve estar com check-in. Pelo menos tentar fazer check-in tantos arquivos quanto possível.

Alguns itens têm problemas de integridade de dados

O relatório lista itens cuja integridade de dados foi comprometida. Esses itens não serão migrados. O Visual SourceSafe utilitário ANALYZE poderá corrigir esses tipos de problemas. Para obter mais informações, consulte as seguintes páginas no site da Microsoft: ANALISAR o utilitário e como detectar e corrigir erros de corrupção de banco de dados no Visual SourceSafe.

Algumas pastas em mapeados contêm histórico de projetos que não está incluso no <ProjectMap> seção

Se uma pasta é movida de um projeto para outro em um Visual SourceSafe banco de dados, o histórico dessa pasta está contido no ambos os originais e atuais projetos. Para migrar a pasta com todos os seu histórico, você deve migrar projetos originais e atuais.

Por exemplo, você está migrando o Visual SourceSafe projeto Projeto2. Este projeto contém a pasta $/ Projeto2/FeatureA, que foi movido de Projeto1 em algum momento de sua história.

Se sua <ProjectMap> contains… da seção	Para example…	Seguir …
Os dois projetos.	`<ProjectMap> <Project Source="$/Project1"></Project> <Project Source="$/Project2"></Project> </ProjectMap>`	A pasta é migrada com o seu histórico completo.
O projeto que originalmente continha a pasta, mas não o projeto contém no momento.	`<ProjectMap> <Project Source="$/Project1"></Project> </ProjectMap>`	A pasta não é migrada.
O projeto que contém a pasta, mas não o projeto que originalmente continha-lo.	`<ProjectMap> <Project Source="$/Project2"></Project> </ProjectMap>`	A pasta é migrada com o seu histórico a partir de quando ele foi movido para o projeto atual. O histórico que ocorreram antes da pasta foi movida para o projeto atual não é migrado.

Para obter mais informações sobre o <ProjectMap> seção do arquivo de configurações, consulte <ProjectMap> Seção anteriormente neste tópico.

Alguns nomes de rótulo não são suportados pelo controle de versão do Team Foundation

Os nomes de rótulo de listas de relatório que serão alterado quando eles são migrados porque eles contêm caracteres que Controle de versão do Team Foundation não oferece suporte.

Migre os dados

Depois de executar o recurso de Analyze, você está quase pronto para migrar seus dados. Antes de executar o comando de migrar, você deve criar um arquivo de configurações de migração. Opcionalmente, você pode especificar como os nomes de usuário são migrados.

Especificar que como os nomes de usuário são migrados.

Você pode controlar como as informações do usuário são migradas de Visual SourceSafe para Controle de versão do Team Foundation. Especificamente, você pode especificar o nome de usuário do recurso de migração deve associar cada conjunto de alterações no histórico de cada item em Controle de versão do Team Foundation. Para fazer isso editando o arquivo de mapeamento de usuário foi criado quando você executou o recurso de Analyze, conforme explicado anteriormente neste tópico.

O arquivo de mapeamento de usuário é opcional. Se você omitir o <UserMap> o elemento do arquivo de configurações, cada changeset baseia-se da seguinte maneira:

O campo do usuário é definido como o nome da conta sob a qual o VSSConverter está sendo executado.
O nome do usuário que executou a ação em seu Visual SourceSafe banco de dados é armazenado no campo comentário.

Exemplo de um arquivo de mapeamento de usuário

Quando você executa o recurso de Analyze, ele compila dados sobre sua Visual SourceSafe os usuários e as armazena em um arquivo XML. Esse arquivo lista todas as Visual SourceSafe usuário nunca executou uma operação de controle de versão na Visual SourceSafe projetos que você está migrando.

O exemplo a seguir mostra um arquivo de mapeamento de usuário foi criado pelo Visual SourceSafe recurso conversor analisar.

<?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>

Você pode especificar o To atributo de none, alguns ou todos os UserMap itens do arquivo de mapeamento de usuário. Por exemplo, você poderia modificar o exemplo anterior da seguinte maneira:

<?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>

Observe que no exemplo anterior, Guest é mapeado para Test1, e nenhum domínio for especificado. Nesses casos, o VSSConverter presume que a conta pertence ao domínio padrão.

Se você não especificar um <UserMap To> atributo, cada changeset baseia-se da seguinte maneira:

O campo do usuário é definido como o nome da conta sob a qual executou o VSSConverter.
O nome do usuário que executou a ação em seu Visual SourceSafe banco de dados é armazenado no campo comentário.
Se você especificar um <UserMap To> atributo e o valor é um usuário válido em um servidor que esteja executando o Team Foundation, o campo do usuário é definido como o nome da conta. Se o valor não é um usuário válido em um servidor que esteja executando o Team Foundation, o VSSConverter exibirá um erro e finalizar o processo de migração.

Criar um arquivo de configurações de migração

Você usa o arquivo de configurações de migração para especificar o que Visual SourceSafe dados que você deseja migrar e controlar vários aspectos de como você deseja migrar o proprietário. A maneira mais fácil de criar esse arquivo é copiar o arquivo que você criou na criar um arquivo de configurações de análise anteriormente neste tópico. Em seguida, você pode adicionar mais dados para o arquivo para torná-la utilizável por um recurso de migração.

O exemplo a seguir mostra um arquivo de configurações de migração.

<?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>

As informações a seguir podem ajudá-lo a modificar o arquivo de configurações para especificar como o recurso de migração irá migrar seus dados.

Destino do projeto < > atributo

Para cada <Project> elemento o <ProjectMap> seção do seu arquivo de configurações, fornecer uma Destination atributo para especificar o caminho do local em seu servidor para Controle de versão do Team Foundation onde você deseja migrar o conteúdo do projeto no seu Visual SourceSafe banco de dados (especificado na Source atributo).

Por exemplo, você deseja migrar o conteúdo do ProjectA no seu Visual SourceSafe banco de dados em ProjectA na raiz de um projeto de equipe que é chamado de Client.

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

Para o valor no atributo de destino seja válida, as seguintes condições devem ser verdadeiras:

A equipe de projeto de Destination atributo (no exemplo anterior, o projeto de equipe é ClientTeamProject) já deve estar localizado na coleção de projeto de equipe antes de iniciar o processo de migração.
Se a pasta do Destination atributo (no exemplo anterior, a pasta é ProjectA) é já localizado no projeto de equipe, a pasta deve estar vazio.
O caminho do Destination atributo do <Project> elemento não deve se sobrepor o caminho a Destination qualquer outro atributo <Project> elementos. Por exemplo, o seguinte <ProjectMap> seção não é válida:
```
<ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProjectA/"></Project>
   <Project Source="$/ProjectB" Destination="$/ClientTeamProjectA/ProjectB"></Project>
</ProjectMap>
```

<TeamFoundationServer> marca

No <Settings> seção, adicione um <TeamFoundationServer> de marca e especifique o nome, a porta, o protocolo e o caminho da coleção de projeto de equipe no servidor que está executando o Team Foundation Server usando o seguinte formato:

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

< label migrar = "false" / > marca

Se sua Visual SourceSafe banco de dados contém muitos rótulos que são aplicados a vários arquivos, o processo de migração pode ser uma prolongada. Se sua equipe não precisar desses dados, você pode configurar o VSSConverter para ignorar as etiquetas adicionando a <Label migrate="false" /> de marca para o <Settings> seção.

< arquivo de saída > atributo

No <Settings> seção, o <Output file> atributo, você pode especificar o caminho e o arquivo onde você deseja que o relatório de migração escrito. Se você não incluir o atributo, o conversor grava o relatório em um arquivo chamado VSSMigrationReport.xml e a coloca no diretório atual.

Execute o comando de migração

Para executar o comando de migração

Clique em Iniciar, aponte para Todos os programas, aponte para 2010 do Microsoft Visual Studio, aponte para Visual Studio Tools, com o botão direito Prompt de comando de 10.0 Visual Studioe, em seguida, clique em Executar como administrador.

Se o O controle de conta de usuário caixa de diálogo exibida, clique em continuar.
No prompt de comando, digite a seguinte linha de comando:

VSSConverter Migrate Settings. XML

Substitua Settings. XML com o caminho e o nome do arquivo de configurações de migração que você criou.

O recurso de migração exibe cada projeto que você está migrando de sua Visual SourceSafe banco de dados e cada pasta na qual os dados serão migrados no seu servidor para Controle de versão do Team Foundation.
Quando solicitado, pressione Y para confirmar a migração.
Quando solicitado, digite a senha do usuário que administra sua Visual SourceSafe banco de dados.

Durante o processo, o recurso de migração exibe seu status atual na janela do Prompt de comando.

Continuar o processo por meio da migração incremental

Se o processo de migração for interrompido por algum motivo, você poderá reiniciar o processo como uma migração incremental a partir do ponto em que o processo foi encerrado. Uma migração incremental pode ser útil se o processo de migração falhou devido a um erro ou problemas de rede. Durante a migração incremental, o conversor irá migrar apenas os dados que não foi migrados nas sessões anteriores.

Para iniciar uma migração incremental, siga as etapas no executar o comando Migrate. Quando o recurso de migração pergunta se deseja executar uma migração incremental, pressione Y.

Limitações de uma migração incremental

Uma migração incremental não terá êxito, a menos que esteja em conformidade com as seguintes restrições:

No seu Visual SourceSafe banco de dados, você deve executar não destruir, limpar, arquivar ou restaurar atividades.
Você não deve alterar o <ProjectMap> seção do seu arquivo de configurações de migração.
Em seu servidor para Controle de versão do Team Foundation, você não deve modificar quaisquer pastas (ou qualquer conteúdo de pastas) que são especificados no <ProjectMap> seção do seu arquivo de configurações de migração.

Verifique se a migração e solucionar questões

Após o recurso de migração, você deve executar as seguintes etapas:

Analise o relatório gerado pelo recurso de migração.
Verifique os dados em seu servidor para Controle de versão do Team Foundation para certificar-se de que os dados foi migrados corretamente.

Depois de executar essas etapas, talvez você precise solucionar problemas.

Como resolver a exceder o limite de armazenamento para Express de SQL Server

Por padrão, o VSSConverter usa SQL Server Express para armazenar metadados temporário. Normalmente, esses metadados requer uma pequena porcentagem do tamanho total dos dados que você migrar. No evento improvável de que sua migração falha porque o limite de 4 GB de SQL Server Express é alcançado, você pode aplicar uma configuração que direciona o conversor para usar um SQL Server implantação em vez disso. Para obter mais informações, consulte <SQL> Elemento anteriormente neste tópico.

Converter arquivos no formato compatível do MS-DOS de nome curto (8.3) (TF227014)

Controle de versão do Team Foundationnão permite nomes de arquivos que estão no formato compatível do MS-DOS de nome curto (8.3) (por exemplo, abcdef~1.txt). Quando você analisar ou tentativa de migrar os arquivos que têm esse nome, aparece um erro de TF227014.

Para contornar esse problema, você pode aplicar temporariamente uma configuração para seu nível de aplicativo para Team Foundation que fará com que ele para permitir que os arquivos que possuem tais nomes. Para fazer isso, você deve definir Allow8Dot3Paths para True no banco de dados de configuração para Team Foundation .

Importante
Para evitar problemas com máquinas cliente que oferecem suporte a nomes curtos de compatível do MS-DOS, depois de concluir o processo de migração, é altamente recomendável que você defina Allow8Dot3Paths para False conforme descrito no procedimento a seguir.

Para executar o procedimento a seguir, Windows PowerShell deve ser habilitada no servidor de camada de aplicativo para Team Foundation. Para obter mais informações, consulte o tópico a seguir no site da Microsoft: Criando scripts com Windows PowerShell.

Permissões necessárias

Para executar este procedimento, você deve ser um membro da administradores grupo no servidor de camada de aplicativo para Team Foundation. For more information, see Permissões de Team Foundation Server.

Para migrar um banco de dados do Visual SourceSafe que contém os arquivos são nomeados no formato nome curto do compatível do MS-dos

Faça logon no servidor de camada de aplicativo para Team Foundation.
Criar um script de Windows PowerShell é chamado de Allow8Dot3Paths.
1. Copie o texto em Script do PowerShell Allow8Dot3Pathse cole o texto no script.
2. Alterar ServerPath para corresponder o caminho de URL que você pode usar para se conectar ao Team Foundation Server. Por padrão, o caminho do servidor é "tfs".
3. Alterar NomeDaColeta para corresponder ao nome da coleção de projeto de equipe no qual você está migrando os dados (por exemplo, DefaultCollection).
  
  O resultado final, por exemplo, seria a seguinte linha no script:
```
$collectionBaseUrl = "https://localhost:8080/tfs/DefaultCollection/";
```
Execute o Allow8Dot3Paths script.
Reciclar o pool de aplicativos para Team Foundation.
1. Clique em Iniciar, clique em Ferramentas administrativase em seguida, clique em Gerenciamento do computador.
2. No painel de navegação, expanda serviços e aplicativos.
3. Clique em Gerenciador de serviços de informações da Internet (IIS), expanda o computador local e clique duas vezes em Pools de aplicativos.
4. Clique com o botão direito no pool de aplicativos e clique em Reciclar.
Execute o comando de migração.

Para obter mais informações, consulte executar o comando migrar.
Modificar o Allow8Dot3Paths script Windows PowerShell que você criou anteriormente, substituindo "true" com "false".
Executar o modificadas Allow8Dot3Paths script.
Reciclar o pool de aplicativos para Team Foundation.
1. Clique em Iniciar, clique em Ferramentas administrativase em seguida, clique em Gerenciamento do computador.
2. No painel de navegação, expanda serviços e aplicativos.
3. Clique em Gerenciador de serviços de informações da Internet (IIS), expanda o computador local e clique duas vezes em Pools de aplicativos.
4. Clique com o botão direito no pool de aplicativos e clique em Reciclar.
Abrir Team Explorere conectar-se à coleção de projeto de equipe no qual você migrou os dados.
Em Gerenciador de controle de código-fonte, renomeie os arquivos com nomes no formato compatível do MS-DOS de nome curto (8.3).

Script do PowerShell Allow8Dot3Paths

# 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

Como o VSSConverter converte seus dados

Team Foundatione Visual SourceSafe têm diferenças funcionais significativos. Como resultado, o VSSConverter deve modificar certos tipos de dados como ele é migrado.

Conjuntos de alterações

Um recurso chave do Controle de versão do Team Foundation é como grupos de alterações em vários arquivos em uma única unidade, quando um usuário faz check-in de um conjunto de alterações. Esta unidade única é conhecida como um changeset.

Visual SourceSafenão tem um recurso que é equivalente a conjuntos de alterações. No entanto, durante o processo de conversão, cada conjunto de alterações é agrupado em um conjunto de alterações, desde que as seguintes condições forem verdadeiras:

As alterações não entrem em conflito uns com os outros. Por exemplo, não há duas ações afetam o mesmo arquivo ou pasta.
As alterações ocorreram dentro de não mais de alguns minutos entre si.
As alterações foram check-in pelo mesmo usuário.
As alterações têm o mesmo comentário de check-in.

For more information, see Trabalhando com conjuntos de alterações.

Compartilhamento e fixando

Em Visual SourceSafe, você pode compartilhar um arquivo em várias pastas. As alterações feitas em um arquivo compartilhado são replicadas entre as pastas em que o arquivo é compartilhado. Controle de versão do Team Foundationnão tem um recurso equivalente. Durante a migração, compartilhado a arquivos no seu Visual SourceSafe projeto são migradas, criando uma cópia independente adicional do item no seu servidor para Controle de versão do Team Foundation.

Controle de versão do Team Foundationnão tem um recurso que é equivalente ao recurso Pin em Visual SourceSafe. Durante a migração, fixados os itens do Visual SourceSafe projeto são convertidos em rotulada itens no seu servidor para Controle de versão do Team Foundation. For more information, see the next section.

Para obter mais informações sobre rótulos em Controle de versão do Team Foundation, consulte Usar rótulos para tirar um instantâneo dos seus arquivos.

Dados de histórico

Cada evento no histórico de um item em seu Visual SourceSafe banco de dados é transferido para seu servidor para Controle de versão do Team Foundation como um conjunto de alterações. Após o processo de migração, você pode exibir esses dados na janela de histórico. For more information, see Usando a janela de histórico.

Algumas alterações nos dados ocorrerem durante a migração.

Como os dados sobre o nome de usuário e o carimbo de data e hora são migrados

Como cada entrada no histórico de um item em seu Visual SourceSafe banco de dados é migrado para um conjunto de alterações em seu servidor para Controle de versão do Team Foundation, ocorrem as seguintes alterações:

O carimbo de data e hora em que o conjunto de alterações é definido como a data e hora quando o item foi migrado.
O carimbo de data e hora original é armazenado no campo comentário do conjunto de alterações.
O nome de usuário é armazenado no campo do usuário ou no campo Comentário das alterações, dependendo do resultado do processo de mapeamento de usuário. Para obter mais informações, consulte especificar como nomes de usuário são migrados anteriormente neste tópico.

Como os tipos de eventos específicos são convertidos

Eventos como, por exemplo, editar, renomear e delete são migrados do seu Visual SourceSafe banco de dados em conjuntos de alterações em seu servidor para Controle de versão do Team Foundation em uma maneira simples. No entanto, o VSSConverter migra alguns eventos de maneiras que não esperar, como mostra a tabela a seguir.

Visual SourceSafe Evento	Como ele é migrado paraTeam Foundation
Adicionar arquivo ou pasta	Este conjunto de alterações é o primeiro evento no histórico de cada arquivo e pasta é migrada. Ao contrário de Visual SourceSafe, nenhum evento é registrado para o pai de cada item filho que ele contém.
Branching	Compartilhamento é uma pré-condição ramificação em Visual SourceSafe, mas Controle de versão do Team Foundation não oferece suporte ao compartilhamento. Portanto, a migração de um arquivo ramificado cria uma cópia do arquivo na pasta de destino. Os arquivos compartilhados no seu Visual SourceSafe banco de dados são migrados para Controle de versão do Team Foundation por copiar a versão do arquivo que existia quando ela foi compartilhada e colocar a cópia na pasta de destino. Daí em diante, cada conjunto de alterações é replicado em ambas as cópias do arquivo até que ocorre o evento de ramificação.
Arquivo de etiquetas	Em Team Foundation, você aplicar um rótulo para uma versão de um arquivo ou pasta. Em Visual SourceSafe, você pode rotular um arquivo, explícita ou implicitamente. Quando um arquivo é rotulado como explicitamente na Visual SourceSafe, uma nova versão do arquivo é criada. Se você receber arquivos usando esse rótulo, você obtém o conteúdo do arquivo que corresponde à versão do arquivo que existiam quando o rótulo foi criado. Para migrar os rótulos explícitos, o conversor leva o rótulo que corresponde à versão rotulada na Visual SourceSafe e o aplica à versão em Team Foundation. No entanto, ele não cria uma nova versão. Quando você aplica um rótulo para uma pasta no Visual SourceSafe, o rótulo é aplicado implicitamente para todos os arquivos e pastas contidos nessa pasta, e o conversor não criar novas versões. Para rótulos implícitos, o conversor não faz nada porque as versões correspondentes em Team Foundation são automaticamente indicados durante a migração dos rótulos explícitas na pasta. Observação Se sua Visual SourceSafe banco de dados contém muitos rótulos que são aplicados a vários arquivos, o processo de migração pode ser uma prolongada.Se sua equipe não precisar desses dados, você pode configurar o VSSConverter para ignorar os rótulos.Para obter mais informações, consulte < Label migrar = "false" / > anteriormente neste tópico.
Pasta de rótulo	Em Visual SourceSafe, quando você aplica um rótulo para uma pasta, todos os arquivos e pastas em que pasta implicitamente são rotuladas e novas versões não são criadas. Durante a migração dessas pastas, o conversor aplica o rótulo para a versão correspondente da pasta na Team Foundation. Esse comportamento aplica automaticamente o rótulo para as versões atuais dos arquivos e pastas dentro da pasta rotulada. Observação Se sua Visual SourceSafe banco de dados contém muitos rótulos que são aplicados a vários arquivos, o processo de migração pode ser uma prolongada.Se sua equipe não precisar desses dados, você pode configurar o VSSConverter para ignorar os rótulos.Para obter mais informações, consulte < Label migrar = "false" />.
Mover pasta	O evento de mover pasta cria uma nova versão da pasta na Team Foundation. VSSConverter não migrará o histórico completo de itens nas pastas movidas, a menos que as pastas de origem e de destino são migradas ao mesmo tempo. Para obter mais informações, consulte de revisão e resolver problemas encontrados pelo recurso analisar. Observação Se o evento de pasta de movimentação é combinado com um evento de restauração, os dados do histórico não podem ser migrados corretamente.
Restaurar	Não há dados de histórico que ocorre antes da migração de um evento de restauração.
PIN e UNPIN	Controle de versão do Team Foundationnão oferece suporte a fixação. VSSConverter migra um arquivo fixado, criando dois rótulos. O PINNED_LATEST rótulo é aplicado às versões dos arquivos fixados fixadas e para a versão mais recente dos arquivos desagregados. O PINNED rótulo é aplicado apenas as versões fixados de arquivos fixos. Após a migração, o PINNED_LATEST rótulo recuperará os mesmos arquivos como um Get Latest em Visual SourceSafe. No entanto, o PINNED_LATEST rótulo pode retornar os arquivos diferentes, se os eventos em vez de verificar ocorreram após um arquivo foi fixado, como renomear ou excluir o arquivo.
Compartilhamento	Controle de versão do Team Foundationnão oferece suporte a compartilhamento. Compartilhado a arquivos no seu Visual SourceSafe banco de dados são migrados para Controle de versão do Team Foundation por copiar a versão do arquivo que existia quando ela foi compartilhada e colocar a cópia na pasta de destino. Daí em diante, cada conjunto de alterações é replicado em ambas as cópias do arquivo.
Cancelamento de exclusão de arquivo ou pasta	Durante a migração de cancelar a exclusão de eventos de um arquivo ou pasta, o conversor repete o evento para criar uma nova versão do arquivo e pasta no Team Foundation. VSSConverter cria um conjunto de alterações que inclui o arquivo ou nome da pasta, data e hora quando foi desfeita a exclusão e o nome de usuário.

Ligações de controle de origem

VSSConverter restaura as ligações de controle de versão para cada solução.

Migrar do Visual SourceSafe

Para migrar dados de seu banco de dados do Visual SourceSafe

Permissões necessárias

Planejar e preparar para o processo de migração

Considere as opções para reduzir o tempo necessário

Agendar a migração com sua equipe.

Copiar e preparar o banco de dados do Visual SourceSafe

Truncar o histórico de itens

Preparar o computador de migração

Fornecer o VSSConverter usar em um banco de dados

Preparar a sua instância do de Team Foundation Server

Analisar seus dados

Criar um arquivo de configurações de análise

<? xml codificação > atributo

< nome do VSSDatabase > atributo

< nome do UserMap > atributo

<ProjectMap> seção

< arquivo de saída > atributo

<SQL> elemento

Execute o comando Analyze

Para analisar um projeto usando o conversor

Analisar e resolver problemas encontrados pelo recurso Analyze

Alguns arquivos estão com Check-Out.

Alguns itens têm problemas de integridade de dados

Algumas pastas em mapeados contêm histórico de projetos que não está incluso no <ProjectMap> seção

Alguns nomes de rótulo não são suportados pelo controle de versão do Team Foundation

Migre os dados

Especificar que como os nomes de usuário são migrados.

Exemplo de um arquivo de mapeamento de usuário

Criar um arquivo de configurações de migração

Destino do projeto < > atributo

<TeamFoundationServer> marca

< label migrar = "false" / > marca

< arquivo de saída > atributo

Execute o comando de migração

Para executar o comando de migração

Continuar o processo por meio da migração incremental

Verifique se a migração e solucionar questões

Como resolver a exceder o limite de armazenamento para Express de SQL Server

Converter arquivos no formato compatível do MS-DOS de nome curto (8.3) (TF227014)

Para migrar um banco de dados do Visual SourceSafe que contém os arquivos são nomeados no formato nome curto do compatível do MS-dos

Script do PowerShell Allow8Dot3Paths

Como o VSSConverter converte seus dados

Conjuntos de alterações

Compartilhamento e fixando

Dados de histórico

Como os dados sobre o nome de usuário e o carimbo de data e hora são migrados

Como os tipos de eventos específicos são convertidos

Ligações de controle de origem

Recursos adicionais