O que significa "consolidação atômica" para um sistema de versão?


34

Uma das razões pelas quais os programadores preferem o SVN ao CVS é ​​que o primeiro permite confirmações atômicas? O que isto significa ?


Isto pode ajudar alguém , ele explica o que é (ele usa git como um exemplo, mas pode ser capaz de ser aplicado para outros VCS)
Fagner Brack

Respostas:


69

Isso significa que, quando você faz uma confirmação no sistema de controle de versão, tudo o que você deseja confirmar entra, ou nada acontece.

No CVS, quando você tenta confirmar, é possível que o commit seja bem-sucedido em vários arquivos e falhe em vários outros (porque eles foram alterados). Isso deixa o repositório em um estado lamentável, porque metade do seu commit não está lá, e é provável que você tenha deixado as coisas em um estado em que elas não serão compiladas ou pior. Agora você precisa se apressar e integrar as alterações para poder confirmar os outros arquivos antes que alguém precise atualizar e obter o conjunto de alterações quebrado.

No SVN, isso não acontecerá - o SVN confirmará tudo o que você mudou ou falhará em todo o conjunto de alterações. Portanto, você nunca deixará o repositório em um estado interrompido devido a problemas de confirmação.


9
Um resultado importante disso é que, se você verificar em qualquer estado, em seguida, o resultado é sempre um estado consistente (com exceção de qualquer usuário-erro como esquecer a cometer um arquivo, é claro): É tanto de antes da submissão ou a partir de depois o commit e nada no meio. No CVS, pode ser "no meio do commit". O comportamento SVN é muito bom para coisas como integração contínua. Para sistemas CVS, esses sistemas usavam para impor um "período de silêncio", onde eles usavam apenas um determinado check-out se não confirmavam mais um determinado número de segundos / minutos após o check-out.
Joachim Sauer

2
memórias sombrias sobre o uso do CVS me atingem enquanto eu leio isso.
shabunc

9
@ Spike - verdade, mas isso é um ato deliberado. No CVS, os problemas podem ocorrer sem culpa alguma, enquanto no SVN você precisa trabalhar nisso.
Michael Kohne

3
@ DanNeely - O CVS os confirma um a um. É por isso que você recebe confirmações parciais - alguns dos arquivos passam e, em seguida, são interrompidos quando atingem um que não pode ser confirmado (devido a um conflito). É um resultado do CVS ter crescido originalmente fora do RCS, eu acho.
Michael Kohne

4
Além disso, observe que no CVS, mesmo se você não acertar um erro e tudo for confirmado, alguém com uma conexão mais rápida poderá atualizar sua árvore de origem na metade do commit, deixando-o em um estado inconsistente. (E eu espero que os carimbos de data e hora sejam distribuídos da mesma forma, para que tentar verificar a árvore em uma data / hora que caia no meio de um commit tenha resultados semelhantes.)
SamB

15

Isso é explicado, por exemplo, no Bye-bye CVS. Fui artigo subvertido escrito por Andy Lester :

Se eu tentar confirmar no Subversion, mas um dos arquivos estiver em conflito ou desatualizado, nenhum deles será confirmado. No CVS, você tem um conjunto de arquivos meio comprometido que precisa corrigir AGORA.

O fato de o CVS forçar o programador a corrigir a mesclagem imediatamente é tão contraproducente quanto possível. Comparado a isso, uma opção para atrasar / cancelar / mesclar cuidadosamente as alterações é um benefício substancial.


Outros benefícios do SVN sobre o CVS explicados no artigo acima são:

  • Versões locais de tudo o que você faz
     
    Se você deseja cvs diff, precisa conectar-se ao seu repositório. Sem conexão de rede, sem diferenças. O Subversion armazena cópias locais originais do que você está trabalhando, então o svn diff funcionará perfeitamente. Deseja começar de novo? O svn revert também funciona desconectado.

  • Os nomes simbólicos das revisões
     
    HEAD são o nome da ponta do tronco no CVS, mas eu sempre quis poder dizer "-r-1" como se fosse nos dias do PVCS. Com o CVS, eu tenho que fazer um cvs log no que estou editando e depois subtrair um. Isso não é divertido. Com o Subversion, posso dizer svn diff -r PREV.

  • Relatório de status real
     
    No CVS, a única maneira de ver se algo no servidor é mais novo é atualizar o cvs e esperar que tudo o que desça não cause conflitos. Com o comando svn status, eu recebo o status real, para que eu possa ver se há conflitos antes de fazer uma atualização.

  • Manuseio útil de conflitos de mesclagem
     
    No CVS, se houver conflitos, você receberá marcadores de conflitos em seu arquivo. No Subversion, você recebe marcadores de conflito, MAIS uma cópia do seu arquivo original pré-conflito, MAIS a versão que desceu do servidor, MAIS a versão que você estava editando originalmente. Então, você deve explicitamente svn resolver filename.txt para informar ao Subversion que você corrigiu o problema. Não é mais necessário voltar acidentalmente ao CVS com marcadores de conflito ainda lá.


8

Isso significa que todas as alterações em todos os arquivos são confirmadas em uma única transação; portanto, todas são bem-sucedidas ou nenhuma.

Isso significa que é menos provável que você faça edições parciais no repositório, causando falhas nas construções. Você ainda pode fazer com que as pessoas se esqueçam de fazer o check-in de todos os arquivos relevantes, mas isso é um problema de processo, e não um problema com o sistema de versão.


então não é uma coisa boa? Caso contrário, uma confirmação parcial resultaria em arquivos fora de sincronia.
4134 Geek

2
sim, é uma coisa boa, confirmações parciais são ruins
jk.
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.