Argumentos contra o check-in de arquivos binários em SCMs

Eu trabalho para uma empresa que cria aplicativos Java principalmente e estou tentando convencer todos a parar de fazer check-in de arquivos binários (dependências e produtos finais) no SCM.

Eles sabem que é uma prática ruim, mas acham que "funciona" e não é realmente um problema, mesmo quando muitas pessoas conhecem o Maven e outras ferramentas para construir além do Ant. Tanto os diretores quanto os programadores (cerca de 50 pessoas) estão prontos para ouvir qualquer argumento contra e até reconhecer que é um desperdício de espaço de backup, mas eu quero ser realmente convincente, porque a mudança de hábito envolveria muito esforço. Quais argumentos você usa para apoiar uma mudança?

Edit: Ok, faz sentido fazer uma distinção entre arquivos que quase não mudam, como dependências e arquivos gerados. Mesmo assim, estou interessado em razões contra esse último.

O espaço de armazenamento é barato e, portanto, esse não é um argumento muito convincente sobre por que você deve ou não fazer o check-in de arquivos.

Em vez disso, você pode recorrer ao objetivo do SCM. Cada arquivo rastreado pelo SCM representa alguma necessidade de gerenciar as alterações distribuídas paralelas que sua equipe está fazendo. Nada disso é realmente aparente até que dois membros da equipe tentem alterar o mesmo arquivo. Resolver essas mudanças é o objetivo do SCM, evitando a substituição acidental do trabalho de outro desenvolvedor e, esperançosamente, automatizando o processo de mesclagem dessas alterações.

Mesclar arquivos binários geralmente é um desafio real, porque não há uma maneira sadia de uma ferramenta de mesclagem genérica adivinhar como um arquivo binário mesclado deve funcionar. Ele não sabe o suficiente sobre como os índices ou ponteiros de deslocamento no arquivo funcionam, a menos que sejam especialmente projetados para reconhecer esse tipo de arquivo específico.

Isso significa que cabe ao desenvolvedor mesclar o arquivo binário manualmente e depois informar ao SCM que o arquivo foi mesclado. Como é um desenvolvedor fazendo isso, a mesclagem pode não cobrir todas as alterações dos check-ins anteriores e, como o arquivo é binário, não há uma maneira automatizada de verificar a mesclagem.

Para formatos binários que realmente representam fontes de projeto, como ativos de arte, essa é uma etapa lamentável, mas necessária. No entanto, os resultados da compilação não são fontes. Não há necessidade de mesclá-los, porque as fontes podem ser mescladas e uma saída de compilação resultante pode ser regenerada. Rastrear e gerenciar essas alterações é 100% desperdício. Desperdiça os recursos do SCM, embora não exageradamente, mas também desperdiça o tempo do desenvolvedor superando as falhas esparsas de mesclagem. O tempo do desenvolvedor é muito caro e qualquer coisa que o desperdice é um câncer.

Por outro lado, há um caso específico em que as saídas da construção devem ser arquivadas. Qualquer versão do projeto que já tenha sido enviada ou implantada provavelmente deve ser mantida indefinidamente. Ter uma cópia exata de bytes em bytes da compilação real com a qual um cliente está tendo problemas pode facilitar muito o suporte a esse cliente, pois você terá a versão exata que ele possui.

Esse backup provavelmente não deve estar no mesmo repositório que o código-fonte, pois eles geralmente seguem agendas diferentes e têm estruturas basicamente diferentes.

Dependências, mesmo em formato binário, devem ser verificadas para que, quando alguém puxe o projeto, ele simplesmente funcione. A principal preocupação não é o tipo de arquivo, mas como o arquivo é criado. A regra geral que uso é que, se puder ser gerado usando outro arquivo, não será verificado - isso significa documentação gerada automaticamente, arquivos binários que eu crio e assim por diante.

Uma das principais vantagens do uso de SCMs é que você pode reconstruir seu sistema a qualquer momento no passado. Portanto, não faz sentido armazenar sua compilação final no seu SCM, pois você pode simplesmente verificar o número da revisão e compilá-lo.

Você menciona dependências ... Seu SCM deve ser configurado para que você possa fazer uma finalização limpa de uma nova máquina (com ambiente de desenvolvimento), clicar em construir e poder construir seu sistema sem precisar instalar mais nada. Portanto, manter dependências binárias no seu SCM é uma boa ideia. As bibliotecas raramente mudam para não ocupar muito espaço.

Quase ninguém faz isso.

Parece redundante incluir os arquivos de origem e de objeto (os arquivos de origem são obviamente necessários). Além de serem desnecessários, os arquivos de objetos podem ocupar muito espaço. Se sua empresa estiver usando um SCM distribuído (Git, Hg, Bzr), esses arquivos binários deverão ser copiados e armazenados entre todos os desenvolvedores.