Quais são as vantagens dos sistemas de controle de versão que versão cada arquivo separadamente?


15

Nos últimos anos, trabalhei com vários sistemas de controle de versão diferentes. Para mim, uma das diferenças fundamentais entre eles é se eles versionam arquivos individualmente (cada arquivo tem sua própria numeração e histórico de versões separados) ou o repositório como um todo (um "commit" ou versão representa um instantâneo de todo o repositório) .

Alguns sistemas de controle de versão "por arquivo":

  • CVS
  • ClearCase
  • Visual SourceSafe

Alguns sistemas de controle de versão "repositório inteiro":

  • SVN
  • Git
  • Mercurial

Na minha experiência, os sistemas de controle de versão por arquivo só levaram a problemas e exigem muito mais configuração e manutenção para serem usados ​​corretamente (por exemplo, "especificações de configuração" no ClearCase). Eu tive muitos casos de um colega de trabalho alterando um arquivo não relacionado e quebrando o que seria idealmente uma linha de desenvolvimento isolada.

Quais são as vantagens desses sistemas de controle de versão por arquivo? Quais problemas os sistemas de controle de versão "repositório inteiro" têm que os sistemas de controle de versão por arquivo não têm?


3
Eu acho que isso acontece principalmente historicamente e agora estamos mudando dos sistemas orientados a arquivos para os orientados a alterações, mas do ponto de vista de hoje é difícil entender por que as pessoas tentaram a abordagem por arquivo. Excelente pergunta!
blubb

Desculpas se esta pergunta parecer argumentativa. É um produto de alguma frustração recente.
9788 Mike Junels

1
@ Mike Daniels: Não (pelo menos para mim), como você claramente pede as vantagens.
blubb

Esses dois pontos de vista são apenas convenções diferentes. Qualquer argumento a favor de um sobre o outro só gera contra-argumentos de partidários do outro lado. Por exemplo, se você quiser um comportamento de "representante completo" no Clearcase, poderá personalizar suas especificações de configuração por data.
Mouviciel 28/06

O SVN tem uma versão por arquivo ou isso também mudou na última versão?
Klaim

Respostas:


12

Na minha experiência, não há: VCS de "repositório inteiro" domina estritamente o VCS "por arquivo".


3

Por arquivo tem uma vantagem quando você cria linhas de produtos (vários produtos de software) a partir do mesmo repositório.

Alguns ambientes de contratação de clientes exigem evidências de que sua queda de código SOMENTE tem as alterações desejadas, e não outras. Isso é bastante fácil se os números de versão do arquivo ainda forem os mesmos.

E este não é um exemplo aleatório que tirei do ar.

Isso aconteceu na última vez em que eu estava enviando atualizações de software ao exército dos EUA para um sistema que eles compraram grande número do meu empregador anterior. O valor em dólar dos contratos era medido em bilhões de dólares fracionários (quando os dólares americanos valiam muito mais)

Por isso, ajuda algumas vezes.

Estranhamente: onde trabalho agora, enviamos a cada cliente um produto diferente também .... (E isso não foi o que eu decidi, caso você esteja se perguntando.)

Suspeito que seja muito mais comum no espaço aeroespacial / de defesa do que em aplicativos da web ou em shrink-wrap.


3
Mas um ramo do repositório de arquivos inteiro também atenderia às mesmas necessidades. Por exemplo, no bzr, as ramificações são completamente independentes da linha principal até a mesclagem (ou compartilhamento de um repositório).
EdA-qa mort-ora-y

1
Não consigo pensar em uma única situação em que a ramificação em um sistema de 'repositório inteiro' não expressasse melhor o estado necessário do que depender do estado externo ao VCS para determinar quais arquivos usar em um VCS "por arquivo". Meu primeiro trabalho depois da uni usou o RCS, um monte de scripts para a versão do projeto e um script de nível superior para a versão dos scripts da versão - um pesadelo absoluto e, sim, também para um projeto militar. * 8 ')
Mark Booth

@ Mark Booth, o cliente sabia quais arquivos foram alterados para as correções desejadas. Assim, a auditoria de configuração física foi por número de controle de versão
Tim Williscroft

O que estou dizendo é que uma versão + um patch auditado requerem informações diferentes em locais diferentes, o VCS e os auditores. Com uma ramificação no sistema 'repositório inteiro', esses dois estados são registrados como entidades separadas. Agora, a mesma informação é duplicada entre o VCS e o sistema de auditoria e deve sempre corresponder. gitpode até diferenciar autor e committer, para que você possa manter um repositório 'auditado' onde você saiba quem criou o patch (o autor) e quem o auditou (o committer). Nos forneça uma situação exemplar e eu inverterei meu -1.
Mark Booth

@ Mark cabine que patches? eles sabiam que seu software era esse conjunto de arquivos A 1.01 B 1.05 D 1.55 E 1.44 F 1.01 e o SVD da versão que eles aceitaram tinha informações de alteração arquivo por arquivo, por exemplo, E alterado para corrigir o defeito 1104, versão antiga 1.43, nova versão 1.44 . Deus nos ajude se tivéssemos mudado F da versão 1.01. A situação era ainda mais complicada porque havia bugs reais que foram corrigidos, eles não queriam mudanças. Essas pessoas queriam o conjunto mínimo de mudanças, para captar apenas alguns recursos escolhidos em um ano de desenvolvimento. Seleção de correções post-hoc.
Tim Williscroft 30/06

3

Não há nenhuma vantagem no controle de versão por arquivo.

As desvantagens, por outro lado, são abundantes e manifestas.


0

Eu poderia dizer que os sistemas de controle de versão "por arquivo" não têm outras vantagens claras além da implementação do VCS. Os codificadores do VCS ficariam felizes em codificar quando fosse uma versão "por arquivo". Eu concordo com o ponto que surgiu historicamente.


0

Não há vantagem na abordagem por arquivo quando você possui arquivos relacionados. Qual é o caso mais comum nas configurações de desenvolvimento.

Em alguns casos peculiares - / etc ou. os arquivos em seu diretório pessoal no Unix são os únicos que tenho rotineiramente - você está lidando (principalmente) com arquivos não relacionados. E ter um sistema que insiste em manter sincronizadas alterações não relacionadas pode ser um incômodo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.