As empresas adquirem outras empresas que usam diferentes sistemas de controle de versão.
Existe uma sabedoria comum sobre como integrar esses sistemas juntos, por exemplo, usando uma ponte Subverson-GIT ou até mesmo decidir usar apenas uma ferramenta sobre outra - e como migrar entre sistemas?
As pessoas usam um conjunto de critérios para essa tomada de decisão, por exemplo, um equivalente ao teste "Joel" no desenvolvimento de software?
Respostas:
Para responder à pergunta de migração da experiência pessoal de várias migrações:
Não tenha medo de colocar a versão atual do software no novo sistema de controle de origem como linha de base e trabalhar a partir daí.
Na grande maioria das vezes você não precisará da história. Isso significa que é uma tarefa a menos a ser executada durante a integração e menos uma coisa a dar errado.
Arquivos / projetos que estão sendo desenvolvidos ativamente em breve irão gerar um novo histórico. Portanto, quando você precisar descobrir por que uma alteração foi feita, é provável que o histórico esteja no repositório atual, pois será uma alteração recente.
Os arquivos / projetos que estavam estáveis antes da migração (todos os itens são iguais) permanecem estáveis após a migração, para que você não precise consultar o histórico. Descobrimos que, se tivéssemos que investigar um bug em um arquivo / projeto tão antigo, ter o histórico não teria nenhum benefício. Contanto que você mantenha o repositório antigo disponível por 6 meses / ano, você terá a referência nesses casos.
No lado gerencial, é principalmente uma questão de:
No lado do projeto, é também uma questão de:
Com freeware ou não, lembre-se de que um software "gratuito" é gratuito como em "liberdade de expressão" (você pode escolher e implantar o que deseja), não como em "cerveja grátis" (ainda custará muito dinheiro no servidor , backup, administração, suporte, ...)
Os critérios mencionados acima são um começo para determinar quais VCS manter e o que abandonar.
Mas neste último caso, você precisa considerar:
Você realmente precisa integrar sistemas diferentes? Em nossa equipe, cada projeto vive em seu próprio repositório e, portanto, suas histórias são independentes. Não temos nenhum problema aqui para trabalhar com alguns projetos em subversão e outros em mercurial, mesmo se houver dependências entre eles.
Se você optar por migrar de um VCS para outro, observe as ferramentas de conversão disponíveis. Pela minha experiência, não há razão técnica para descartar a história dos projetos.
Acho que entendi algo implícito na pergunta e em outras respostas. É o fato de que os VCS também são usados para gerenciar dependências. Eu sei que é bastante comum usar recursos de VCS, como svn:externalsintegrar um repositório (a dependência) a outro.
Acho que a razão (técnica) pela qual nossa equipe não sente a necessidade de conectar (ou integrar) nossos 2 sistemas diferentes é que temos uma ferramenta separada para gerenciar dependências. Nosso repositório não se conhecem.
Muitas boas respostas. Outra coisa a se pensar é não deixar que os membros da equipe se acostumem a pensar em mudar o VC. Haverá um revés com a migração, uma curva de aprendizado etc., mas se tiverem muitos problemas, eles deverão questionar seu nível de habilidade e / ou cooperação.