Usando o Subversion como um repositório de artefatos versus uma ferramenta de gerenciamento de artefatos específica

TL; DR: Por que usar algo como Apache Archiva ou Sonatype Nexus como um repositório de artefatos em vez do Subversion?

O sistema de compilação que eu uso atualmente possui muitos blobs binários (imagens, arquivos de som, binários compilados etc.), tanto como entrada quanto como saída de nossas compilações. Nosso sistema para gerenciar estes é muito ad hoc; alguns são verificados em nosso repositório Subversion junto com nosso código, outros são armazenados em outros lugares fora de qualquer controle formal de versão.

Estou procurando consolidar isso, para termos algo mais consistente e fácil de usar e que separa artefatos binários do código.

O Google me diz que há uma seleção de repositórios de artefatos disponíveis ( Archiva , Nexus , Artifactory , ...), mas, lendo o artigo, não vejo nenhuma vantagem em usá-los no Subversion. Isso cuidará dos binários para nós - já o faz para alguns de nossos binários, apenas queremos reorganizar o layout do repositório para separá-los do código - e tem a notável vantagem de já termos servidores e conhecimentos do Subversion.

Então. Qual é a vantagem de usar um sistema de gerenciamento de artefato dedicado em vez de usar uma ferramenta geral de controle de versão como o Subversion?

Resposta curta: Geralmente, você não precisa de um histórico de artefatos binários e alterações nesses artefatos, apenas de versões específicas.

Resposta mais longa: toda vez que você confirma uma pequena alteração em um arquivo binário, os sistemas de controle de versão não têm como criar um delta - uma diferença entre os dois arquivos -, criando uma cópia totalmente nova.

Em um CVCS, como o SVN, isso não é tão complicado, porque você só tem uma cópia central do seu repositório - sua cópia local é apenas uma versão. (Embora, mesmo assim, seu repositório possa se tornar muito grande, tornando os checkins mais lentos.) Mas o que acontece se você mudar posteriormente para um DVCS, onde cada cópia de um repositório tem o histórico completo de cada arquivo? O tamanho das mudanças se torna muito relevante lá.

E o que isso lhe dá em troca da dor? A única coisa que ele oferece é poder voltar para uma versão anterior do seu repositório e saber que você possui os binários corretos para essa versão.

Mas você precisa de todo o binário no seu repositório para fazer isso? Ou você pode simplesmente ter um arquivo de texto, informando ao processo de construção quais versões extrair de outro repositório em outro lugar?

O último é o que é oferecido pelos repositórios de artefatos em geral.

Além disso, alguns dos mais profissionais, como o Nexus, também fornecerão informações sobre o licenciamento de artefatos de terceiros, para que você não corra o risco de se deparar com alguma cláusula sutil no que você acredita ser uma biblioteca FOSS.

Usamos o SVN como um repositório para compilações de versões e funciona muito bem. Temos em um repositório de versão melhor que 30 GB de várias compilações de versões e ele executa bem as compilações para implantação.

algumas das vantagens de fazer isso são ..

• Os binários adicionados ao SVN são compactados em cerca de 60 a 70% na economia média de espaço.
• O SVN serve como uma biblioteca (artefativa) para liberações e o backup do repositório é feito para fins de recuperação de falhas.
• O SVN via https permite a entrega segura do código de liberação em uma DMZ.