Pergunta

Usar interfaces online para um sistema de controle de versão é uma ótima maneira de ter um local publicado para as versões mais recentes do código.Por exemplo, eu tenho um pacote LaTeX aqui (que é liberado para o CTAN sempre que as alterações são verificadas para realmente funcionarem):

http://github.com/wspr/pstool/tree/master

O pacote em si é derivado de um único arquivo (neste caso, pstool.tex) que, quando processado, produz a documentação, o leia-me, o arquivo do instalador e os arquivos reais que compõem o pacote conforme ele é usado pelo LaTeX.

Para facilitar o download desse material para os usuários, incluo todos os arquivos derivados mencionados acima no próprio repositório, bem como o arquivo mestre pstool.tex.Isso significa que terei o dobro do número de alterações sempre que fizer commit porque o arquivo do pacote pstool.sty é um subconjunto gerado do arquivo mestre.

Isso é uma perversão do controle de versão?


@Jon Limjap levantou um bom ponto:

Existe outra maneira de publicar seus arquivos gerados em outro lugar para download, em vez de depender do seu controle de versão para ser seu servidor de download?

Esse é realmente o cerne da questão neste caso.Sim, as versões lançadas do pacote podem ser obtidas em outro lugar.Portanto, realmente faz mais sentido versionar apenas os arquivos não gerados.

Por outro lado, @Madircomenta que:

a conveniência, que é real e repetida, supera o custo, que é suportado nos bastidores

também é bastante pertinente porque se um usuário encontrar um bug e eu corrigi-lo imediatamente, ele poderá ir ao repositório e obter o arquivo necessário para continuar trabalhando sem precisar executar nenhuma etapa de "instalação".

E este, eu acho, é o caso de uso mais importante para meu conjunto específico de projetos.

Foi útil?

Solução

Estou usando o Tortoise SVN para desenvolvimento de pequenos sistemas ASP.NET.A maior parte do código é interpretada como ASPX, mas há cerca de uma dúzia de DLLs binárias geradas por uma etapa de compilação manual.Embora não faça muito sentido ter esses códigos-fonte versionados em teoria, certamente é conveniente garantir que eles sejam espelhados corretamente do ambiente de desenvolvimento para o sistema de produção (um clique).Além disso - em caso de desastre - a reversão para a etapa anterior é novamente um clique no SVN.

Então eu mordi a bala e os incluí no arquivo SVN - a conveniência, que é real e repetida, supera o custo, que é suportado nos bastidores.

Outras dicas

Não versionamos arquivos que possam ser gerados automaticamente usando scripts incluídos no próprio repositório.A razão para isso é que após o checkout, esses arquivos podem ser reconstruídos com um único clique ou comando.Em nossos projetos procuramos sempre facilitar ao máximo isso, evitando assim a necessidade de versionamento desses arquivos.

Posso imaginar um cenário em que isso poderia ser útil se 'marcar' versões específicas de um produto, para uso em um ambiente de produção (ou qualquer ambiente que não seja de desenvolvimento), onde as ferramentas necessárias para gerar a saída podem não estar disponíveis.

Também usamos alvos em nossos scripts de construção que podem criar e fazer upload de arquivos com uma versão lançada de nossos produtos.Isso pode ser carregado em um servidor de produção ou em um servidor HTTP para download pelos usuários de seus produtos.

Não necessariamente, embora as práticas recomendadas para controle de origem aconselhem que você não inclua arquivos gerados, por motivos óbvios.

Existe outra maneira de publicar seus arquivos gerados em outro lugar para download, em vez de depender do seu controle de versão para ser seu servidor de download?

Normalmente, os arquivos derivados não devem ser armazenados no controle de versão.No seu caso, você poderia criar um procedimento de lançamento que criasse um tarball que incluísse os arquivos derivados.

Como você disse, manter os arquivos derivados no controle de versão apenas aumenta a quantidade de ruído com a qual você precisa lidar.

Em alguns casos, sim, mas é mais um caso de uso do tipo sysadmin, onde os arquivos gerados (digamos, arquivos de zona DNS criados a partir de um script) têm interesse intrínseco por si só, e o controle de revisão é uma trilha de auditoria mais linear do que controle de origem de ramificação e marcação.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top