Convertendo um repositório subversion remoto muito grande em um repositório Git reduzido

5

Tenho o prazer de receber mais de 14 anos de repositório de subversão que consiste em dois elementos-chave:

  1. 111.000 revisões, cerca de 10% das quais são substanciais;
  2. O despejo do repositório é de cerca de 73 GB, devido a um grande número de arquivos de dados binários que foram atualizados, adicionados e modificados ao longo dos anos.

Aqui está o que eu gostaria de fazer, mas não tenho certeza se é possível: gostaria de despir o histórico dos arquivos binários e manter apenas as alterações no código. Então converta isso para git. Quais são suas recomendações?

    
por Ben 03.05.2018 / 21:13
fonte

2 respostas

4

not sure if it's possible: I'd like to strip the history of the binary files, only keeping the code changes. Then convert that to git.

Eu não tentei isso sozinho, mas tenho certeza que isso é possível quando você aborda a tarefa exatamente na ordem descrita acima:

  1. tira o histórico dos arquivos binários, mantendo apenas as alterações no código, no SVN primeiro

  2. migre para o Git depois .

O passo 1 pode ser realizado movendo os arquivos binários com seu histórico para alguma pasta temporária (dentro do repositório, por exemplo, com svn move ). Em seguida, crie uma nova cópia deles no diretório de trabalho local dos seus projetos e verifique-os como se fossem novos arquivos - para que esses novos arquivos não tenham histórico. Então você usa o procedimento descrito nesta pergunta de falha do servidor para se livrar da pasta temporária (utilizando svnadmin dump , svndumpfilter , svnadmin load ), que exclui o histórico completo.

Observe desta forma sempre que você verificar uma revisão mais antiga do projeto, os arquivos binários ficarão completamente ausentes. Para evitar que isso se torne um problema, considere a estratégia de manter o antigo repositório SVN online, como sugerido pelo @RobertHarvey.

    
por 03.05.2018 / 22:31
fonte
3

OP aqui. Para a posteridade, gostaria de acrescentar qual foi a minha solução final para este problema. Vou manter a melhor resposta marcada, porque é realmente a melhor resposta quando as coisas correm bem.

Primeiro, tentei a resposta selecionada do Doc Brown: link

Mas o comando svnadmin dump falhou na metade do processo (cerca de 1 dia para o despejo), com uma revisão corrompida. Este foi um ponto consistente de falha. Tentativas de ignorar essa referência específica, através do uso cuidadoso dos sinalizadores de revisão para svnadmin dump, consegui produzir um despejo completo, no entanto, tentativas de filtrar arquivos binários do arquivo de despejo de 73 GB foram atendidas com mais frustração. Consegui fazer alguns depósitos de determinados ramos, mas isso foi inútil para mim em uma migração completa.

Por fim, acabei usando o git-svn para fazer isso: nohup git svn init https://myurl.com/projects/myproject/ --no-minimize-url --no-metadata --stdlayout &

Usar git-svn em um repositório tão grande não foi isento de problemas. É regularmente bloqueado durante o processamento. Felizmente, git svn fetch poderia ser emitido para retomar a conversão em cada ponto de parada. Eu escrevi um pequeno script wrapper que continuaria a emitir esse comando após a falha.

Tendo dito tudo isso, o git-svn não é recomendado para esta tarefa, veja este artigo: link

Mas esta foi a única ferramenta que pude trabalhar. Para remover os arquivos binários, usei o link do repositório BFG mais limpo.     

por 26.09.2018 / 17:54
fonte