Quais são as melhores práticas para migrar entre sistemas de controle de versão?

Question

Existem cerca de 200 projetos em cvs e pelo menos 100 projetos em vss.Alguns são códigos inativos no modo de manutenção.Alguns são aplicativos legados.Alguns são aplicativos antigos que não estão mais em uso.Cerca de 10% estão em desenvolvimento ativo.O plano é mudar tudo para forçar meu final de ano de 2009.

Alguém já fez uma grande migração como essa?

Alguém encontrou as melhores práticas para passar de cvs para forçosamente?Ou uma migração semelhante.Alguma dica a ser observada?

Answer 1

Do lado do VSS, existem ferramentas de conversão disponíveis para ajudar na migração.Eles podem principalmente manter o histórico de versões (há advertências explicadas no leia-me e na documentação).Migrei mais de 50 projetos VSS para o perforce usando a ferramenta VSS to perforce.Tirar os dados do VSS pode ser um pouco complicado e não muito rápido, mas funciona.Se você tiver acesso direto aos discos (ou seja,não através de um compartilhamento de rede) para o repositório VSS, a conversão pode ser muito mais rápida.Você pode encontrar informações sobre os scripts aqui.

Existe uma página semelhante para o CVS forçar a conversão aqui, embora eu não tenha experiência direta com isso.Esses links são bons lugares para começar.Você também pode pesquisar nas listas de discussão do Perforce na Base de Conhecimento do Perforce localizada aqui.Tenho certeza de que você poderá encontrar algumas informações de conversão nos arquivos da lista de discussão.

Migre seus projetos antigos primeiro.Você pode ter certeza de que seu processo funciona.Quando migramos o código ativo para o Perforce, tirei um fim de semana e basicamente retirei o acesso aos servidores e movi o código para o Perforce.Honestamente, foi uma migração muito fácil e quando as pessoas voltaram na segunda-feira, estavam prontas para partir.Você pode pensar em preparar seus funcionários com folhas de dicas do Perforce depois de começar a fazer a migração.

A maior pegadinha pode ser preparar seu pessoal para usar o Perforce.Se eu tivesse feito tudo de novo, teria migrado primeiro nossos projetos ativos menores e preparado um número menor de pessoas para usar o Perforce de uma só vez.Do jeito que estava, tive que treinar mais de 120 pessoas no primeiro dia após a migração e isso foi um pouco demais.Além disso, certifique-se de que você não tenha mais de 100 pessoas acessando seu servidor para uma nova sincronização no primeiro dia.Acabamos desativando nosso servidor várias vezes durante os primeiros dias.Usamos um servidor Windows de 32 bits que eu não recomendaria.Agora temos um servidor Windows de 64 bits e é muito mais robusto.Se você puder, eu usaria o Linux como sistema operacional para o seu servidor forçado.Novamente, deve haver boas informações no site do Perforce sobre desempenho.

Answer 2

Não tive que fazer algo dessa escala, mas tenho algumas ideias.Primeiro, comece pegando um projeto pequeno e sem importância e migre-o.Isso lhe dará uma ideia de quantos problemas serão necessários para migrar o restante dos projetos.Imediatamente depois disso, você deve escolher um projeto de tamanho médio, pois pode haver problemas com a migração de um projeto maior (por exemplo, com filiais) que podem não ser aparentes em um projeto pequeno.

Certifique-se de gastar um pouco de tempo vendo como é fácil converter projetos cvs em vss, ou vice-versa.Se converter de vss para forçosamente for uma verdadeira dor de cabeça, você pode converter vss para cvs e depois para forçosamente.Não perca dias nisso, mas isso pode ajudá-lo a sair de uma situação complicada.Acho que a chave aqui é incrementar.

Os backups são bons.Período.

Considere uma data limite, e quaisquer projetos que estejam inativos, e mais antigos, devem ser desativados.Confira a revisão final e armazene-a no Perforce.Você realmente precisa de um código visual básico de 15 anos?

Answer 3

Faça o que fizer, mantenha os repositórios antigos em modo somente leitura em algum lugar.

Answer 4

Perdoe-me por responder uma pergunta com outra pergunta, mas não Forçosamente fornecer ferramentas para isso?Ou, pelo menos, documentação?Eu estaria batendo no meu vendedor do Perforce...

Answer 5

Considere não migrar projetos mortos e inativos.Basta colocar seus repositórios em modo somente leitura.Os dados ainda estarão disponíveis se necessário e você economiza tempo para migrá-los.Basta migrar os 10% que estão em uso.Documente o processo completamente.

Se um dos projetos não migrados for ressuscitado em algum momento no futuro, você poderá migrá-lo facilmente usando sua documentação como referência.

Answer 6

Migramos nosso repositório svn com uma ferramenta que escrevemos e apenas fizemos a revisão principal de nossos projetos starteam.

Cuidado com as diferenças entre checkins de arquivo único (CVS) e conjuntos de alterações de vários arquivos (Perforce).

Cuidado com as filiais: espaço separado (CVS) vs.ramificações no espaço do caminho do arquivo (Perforce).