Diferença entre GIT e CVS

StackOverflow https://stackoverflow.com/questions/802573

  •  03-07-2019
  •  | 
  •  

Pergunta

Qual é a diferença entre os sistemas de controle de versão Git e CVS?

Tenho usado CVS com satisfação há mais de 10 anos e agora me disseram que o Git é muito melhor.Alguém poderia explicar qual é a diferença entre os dois e por que um é melhor que o outro?

Foi útil?

Solução

A principal diferença é que (como já foi dito em outras respostas) o CVS é ​​um (antigo) sistema de controle de versão centralizado, enquanto o Git é distribuído.

Mas mesmo se você usar controle de versão para desenvolvedor único, em máquina única (conta única), existem algumas diferenças entre Git e CVS:

  • Configurando repositório.Git armazena repositório em .git diretório no diretório superior do seu projeto;O CVS requer a configuração do CVSROOT, um local central para armazenar informações de controle de versão para diferentes projetos (módulos).A consequência desse design para o usuário é que importar fontes existentes para o controle de versão é tão simples quanto "git init && git add .&& git commit" no Git, enquanto é mais complicado em CVS.

  • Operações atômicas.Como o CVS no início era um conjunto de scripts em torno do sistema de controle de versão RCS por arquivo, os commits (e outras operações) não são atômicos no CVS;se uma operação no repositório for interrompida no meio, o repositório poderá ficar em um estado inconsistente.No Git todas as operações são atômicas:ou eles são bem-sucedidos como um todo ou falham sem quaisquer alterações.

  • Conjuntos de alterações.As alterações no CVS são por arquivo, enquanto as alterações (commits) no Git sempre se referem ao projeto inteiro.Isto é muito importante mudança de paradigma.Uma das consequências disso é que é muito fácil no Git reverter (criar uma mudança que desfaça) ou desfazer todo mudar;outra consequência é que no CVS é ​​fácil fazer checkouts parciais, enquanto atualmente é quase impossível no Git.O fato de as alterações serem agrupadas por arquivo levou à invenção do formato GNU Changelog para mensagens de commit no CVS;Os usuários do Git usam (e algumas ferramentas do Git esperam) uma convenção diferente, com uma única linha descrevendo (resumindo) as alterações, seguida por uma linha vazia, seguida por uma descrição mais detalhada das alterações.

  • Nomeando revisões/números de versão.Há outro problema relacionado ao fato de que no CVS as alterações são por arquivo:números de versão (como você pode ver às vezes em expansão de palavras-chave, veja abaixo) como 1.4 reflete quanto tempo determinado arquivo foi alterado.No Git cada versão de um projeto como um todo (cada commit) tem seu nome exclusivo dado pelo ID SHA-1;normalmente os primeiros 7 a 8 caracteres são suficientes para identificar um commit (você não pode usar um esquema de numeração simples para versões em um sistema de controle de versão distribuído - isso requer autoridade de numeração central).No CVS para ter o número da versão ou nome simbólico referente ao estado do projeto como um todo você usa Tag;o mesmo acontece no Git se você quiser usar um nome como 'v1.5.6-rc2' para alguma versão de um projeto ...mas as tags no Git são muito mais fáceis de usar.

  • Ramificação fácil.As filiais no CVS são, na minha opinião, excessivamente complicadas e difíceis de lidar.Você precisa marcar as ramificações para ter um nome para uma ramificação inteira do repositório (e mesmo isso pode falhar em alguns casos, se bem me lembro, devido ao tratamento por arquivo).Adicione a isso o fato de que o CVS não tem rastreamento de mesclagem, então você deve se lembrar ou marcar manualmente mesclagens e pontos de ramificação e fornecer manualmente as informações corretas para "cvs update -j" para mesclar ramificações, e isso torna a ramificação desnecessária e difícil de usar.No Git criar e mesclar ramificações é muito fácil;O Git lembra todas as informações necessárias por si só (portanto, mesclar um branch é tão fácil quanto "git merge nome da filial")...era necessário, porque o desenvolvimento distribuído naturalmente leva a múltiplas ramificações.

    Isso significa que você pode usar ramos de tópico, ou sejadesenvolver um recurso separado em várias etapas em uma ramificação de recurso separada.

  • Renomear (e copiar) rastreamento.As renomeações de arquivos não são suportadas no CVS e a renomeação manual pode quebrar o histórico em dois ou levar a um histórico inválido, onde você não pode recuperar corretamente o estado de um projeto antes de renomeá-lo.O Git usa detecção heurística de renomeação, com base na similaridade de conteúdo e nome de arquivo (esta solução funciona bem na prática).Você também pode solicitar a detecção de cópia de arquivos.Isso significa que:

    • ao examinar o commit especificado, você obterá informações de que algum arquivo foi renomeado,
    • mesclar corretamente leva em consideração as renomeações (por exemplo, se o arquivo foi renomeado apenas em uma ramificação)
    • "git culpa", o (melhor) equivalente de "cvs annotate", uma ferramenta para mostrar o histórico de linhas do conteúdo de um arquivo, pode acompanhar o movimento do código também entre renomeações

  • Arquivos binários.O CVS tem apenas um suporte muito limitado para arquivos binários (por exemplo,imagens), exigindo que os usuários marquem arquivos binários explicitamente ao adicioná-los (ou posteriormente usando "cvs admin", ou por meio de wrappers para fazer isso automaticamente com base no nome do arquivo), para evitar a confusão do arquivo binário por meio de conversão de fim de linha e expansão de palavras-chave .O Git detecta automaticamente arquivos binários com base no conteúdo da mesma forma que o CNU diff e outras ferramentas fazem;você pode substituir essa detecção usando o mecanismo gitattributes.Além disso, os arquivos binários são seguros contra a manipulação irrecuperável graças ao padrão 'safecrlf' (e ao fato de que você precisa solicitar a conversão de fim de linha, embora isso possa estar ativado por padrão, dependendo da distribuição), e aquela palavra-chave (limitada) a expansão é uma 'opção' estrita no Git.

  • Expansão de palavras-chave.O Git oferece um conjunto muito limitado de palavras-chave em comparação com o CVS (por padrão).Isto se deve a dois fatos:as alterações no Git são por repositório e não por arquivo, e o Git evita modificar arquivos que não foram alterados ao mudar para outro branch ou retroceder para outro ponto no histórico.Se você deseja incorporar o número de revisão usando Git, você deve fazer isso usando seu sistema de compilação, por exemplo.seguinte exemplo de script GIT-VERSION-GEN em fontes do kernel Linux e em fontes Git.

  • Alterando confirmações.Porque em VCS distribuídos, como o Git, o ato de publicação é separado da criação de um commit, é possível alterar (editar, reescrever) parte não publicada do histórico sem incomodar outros usuários.Em particular, se você notar um erro de digitação (ou outro erro) na mensagem de commit, ou um bug no commit, você pode simplesmente usar "git commit --amend".Isso não é possível (pelo menos não sem hackers pesados) no CVS.

  • Mais ferramentas.O Git oferece muito mais ferramentas que o CVS.Um dos mais importantes é "git bisect" que pode ser usado para encontrar um commit (revisão) que introduziu um bug;se seus commits forem pequenos e independentes, será bastante fácil descobrir onde está o bug.

Se você estiver colaborando com pelo menos outro desenvolvedor, também encontrará as seguintes diferenças entre Git e CVS:

  • Confirmar antes de mesclar Git usa confirmar antes de mesclar em vez de, como o CVS, mesclar antes de confirmar (ou atualizar-então-comprometer).Se enquanto você estava editando arquivos, preparando-se para criar um novo commit (nova revisão) alguém criou um novo commit no mesmo branch e ele agora está no repositório, o CVS força você a primeiro atualizar seu diretório de trabalho e resolver conflitos antes de permitir que você faça o commit.Este não é o caso do Git.Primeiro você confirma, salvando seu estado no controle de versão, depois mescla outras alterações do desenvolvedor.Você também pode pedir ao outro desenvolvedor para fazer a mesclagem e resolver conflitos.

    Se preferir ter um histórico linear e evitar fusões, você sempre pode usar confirmar-mesclar-recomprometer fluxo de trabalho via "git rebase" (e "git pull --rebase"), que é semelhante ao CVS, pois você reproduz suas alterações sobre o estado atualizado.Mas você sempre se compromete primeiro.

  • Não há necessidade de repositório central Com o Git não há necessidade de ter um único local central onde você confirma suas alterações.Cada desenvolvedor pode ter seu próprio repositório (ou repositórios melhores:privado aquele em que ele faz o desenvolvimento, e público aquele onde ele publica aquela parte que está pronta), e podem puxar/buscar repositórios um do outro, de forma simétrica.Por outro lado, é comum que projetos maiores tenham socialmente repositório central definido/nomeado do qual todos extraem (obtêm alterações).

Finalmente, o Git oferece muito mais possibilidades quando é necessária a colaboração com um grande número de desenvolvedores.Abaixo estão as diferenças entre o CVS no Git para diferentes estágios de interesse e posição em um projeto (sob controle de versão usando CVS ou Git):

  • espreitador.Se você estiver interessado apenas em obter as alterações mais recentes de um projeto, (nenhuma propagação de suas alterações) ou fazendo privado desenvolvimento (sem contribuir para projetos originais);ou você usa projetos estrangeiros como base para seu próprio projeto (as alterações são locais e não faz sentido publicá-las).

    Git suporta aqui anônimo não autenticado acesso somente leitura por meio de personalização eficiente git://protocolo, ou se você estiver atrás de bloqueio de firewall DEFAULT_GIT_PORT (9418) você pode usar HTTP simples.

    Para o CVS, a solução mais comum (pelo que entendi) para acesso somente leitura é Conta de visitante para protocolo 'pserver' em CVS_AUTH_PORT (2401), normalmente chamado de “anônimo” e com senha vazia.As credenciais são armazenadas por padrão em $HOME/.cvspass arquivo, então você deve fornecê-lo apenas uma vez;ainda assim, isso é um pouco uma barreira (você precisa saber o nome da conta de convidado ou prestar atenção às mensagens do servidor CVS) e um aborrecimento.

  • desenvolvedor adicional (colaborador folha).Uma forma de propagar suas mudanças no OSS é enviando patches por e-mail.Esta é a solução mais comum se você for (mais ou menos) um desenvolvedor acidental, enviando uma única alteração ou uma única correção de bug.POR FALAR NISSO.o envio de patches pode ser feito por meio do quadro de revisão (sistema de revisão de patches) ou meios semelhantes, não apenas por e-mail.

    O Git oferece aqui ferramentas que auxiliam neste mecanismo de propagação (publicação) tanto para o remetente (cliente), quanto para o mantenedor (servidor).Para quem deseja enviar suas alterações por e-mail existe "git rebase" (ou "git pull --rebase") ferramenta para reproduzir suas próprias alterações sobre a versão upstream atual, para que suas alterações estejam sobre a versão atual (são recentes) e "patch de formato git" para criar e-mail com mensagem de commit (e autoria), altere a forma do formato diff unificado (estendido) (mais diffstat para facilitar a revisão).O mantenedor pode transformar esse e-mail diretamente em commit preservando todas as informações (incluindo a mensagem de commit) usando "eu sou".

    O CVS não oferece essas ferramentas:você pode usar "cvs diff" / "cvs rdiff" para gerar alterações e usar o patch GNU para aplicar alterações, mas até onde eu sei, não há como automatizar a aplicação da mensagem de commit.O CVS foi feito para ser usado no estilo cliente <-> servidor...

  • tenente.Se você é o mantenedor de uma parte separada de um projeto (subsistema), ou se o desenvolvimento do seu projeto segue o fluxo de trabalho de "rede de confiança" usado no desenvolvimento do kernel Linux...ou apenas se você tiver seu próprio repositório público e as alterações que deseja publicar forem muito grandes para serem enviadas por e-mail como série de patches, você pode enviar solicitação pull para (principal) mantenedor do projeto.

    Esta é uma solução específica para distribuído sistemas de controle de versão, então é claro que o CVS não suporta essa forma de colaboração.Existe até uma ferramenta chamada "git request-pull" que ajuda a preparar o email para enviar ao mantenedor com solicitação de pull do seu repositório.Graças ao "git bundle" você pode utilizar este mecanismo mesmo sem ter repositório público, enviando pacote de alterações via email ou sneakernet.Alguns sites de hospedagem Git como GitHub tenha suporte para notificar que alguém está trabalhando (publicou algum trabalho) em seu projeto (desde que use o mesmo site de hospedagem Git) e para PM-ing uma espécie de pull request.

  • desenvolvedor principal, ou sejaalguém que publicar diretamente suas alterações (no repositório principal/canônico).Esta categoria é mais ampla para sistemas de controle de versão distribuídos, pois ter vários desenvolvedores com acesso de gravação ao repositório central não é apenas um fluxo de trabalho possível (você pode ter um único mantenedor que empurra mudanças no repositório canônico, um conjunto de tenentes/mantenedores de subsistemas dos quais ele extrai e uma ampla gama de desenvolvedores leaf que enviam patches via correio para a lista de discussão do mantenedor/projeto ou para um dos tenentes/submantenedores).

    Com o Git você tem a opção de usar Protocolo SSH (protocolo git envolto em SSH) para publicar alterações, com ferramentas como "git shell" (para ajudar na segurança, limitando o acesso de contas shell) ou Gitose (para gerenciar o acesso sem exigir contas shell separadas), e HTTPS com WebDAV, com autenticação HTTP comum.

    Com o CVS há uma escolha entre customização não criptografado (texto simples) servidor pserver protocolo ou usando shell remoto (onde você realmente deveria usar SSH) para publicar suas alterações, que por centralizado sistema de controle de versão significa submeter suas alterações (criar commits).Bem, você também pode encapsular o protocolo 'pserver' usando SSH, e existem ferramentas de terceiros que automatizam isso ...mas não acho que isso seja tão fácil quanto, por exemplo.Gitose.

Em geral, os sistemas de controle de versão distribuídos, como o Git, oferecem uma seleção muito mais ampla de possíveis fluxos de trabalho.Com sistemas de controle de versão centralizados, como o CVS, é necessário distinguir entre pessoas com acesso de commit ao repositório e aquelas sem...e o CVS não oferece nenhuma ferramenta para ajudar a aceitar contribuições (via patches) de pessoas sem acesso de commit.

Karl Fogel em Produzindo software de código aberto na seção sobre controle de versão afirma que é melhor não fornecer controles muito rígidos e rigorosos em áreas onde é permitido fazer alterações no repositório público;é muito melhor confiar (para isso) em restrições sociais (como revisão de código) do que em restrições técnicas;sistemas de controle de versão distribuídos reduzem ainda mais esse IMHO ...

HTH (Espero que ajude)

Outras dicas

Git é a DVCs, em oposição ao CVS ser centralizado. Descrição simplista será: você obtém todos os benefícios do controle de versão quando não estiver conectado a algum de vários repositórios possíveis, além de operações são mais rápidas.

O site do Git Explica isso melhor provavelmente.

Meu recurso para animais de estimação é capaz de se cometer quando offline. E a velocidade, a velocidade pura na qual tudo, exceto empurrar e puxar, acontece. (E essas operações são por design não destrutivas, para que você possa empurrar/puxar ao tomar um café se o seu repositório central estiver atrasado.) Outra coisa boa é que ele vem incluído nas baterias: o embutido gitk é um visualizador de história bom o suficiente; git gui é uma ferramenta de compromisso boa o suficiente; com colorização da saída, git add -i, git add -p, git rebase -i são boas interfaces interativas; git daemon e git instaweb são bons o suficiente para a colaboração ad-hoc se você não quiser / não pode mexer com o seu repositório central.

Também sou um usuário de mais de 10 anos de CVS, embora também goste do Git, e com o tempo chegará a preferir, embora a maioria dos projetos em que trabalho atualmente use CVs, ou SVN, e não podemos parecer Para obter a burocracia, onde trabalho convencido a nos deixar dar um soco no Firewall.

Algumas coisas que tornam o CVS mais agradável do que seriam CVSPs, e outra são os scripts de patch de Andrew Morton ou colcha. O CVSPS permite reconstituir os vários arquivos de uma confirmação em um único patch (e, assim Trabalhe com as coisas Mutliple simultaneamente, mantendo -as separadas antes de se comprometer. O CVS tem suas peculiaridades, mas estou acostumado com a maioria delas.

"Felizmente usando o CVS por mais de x anos", é uma ideia interessante :-) É um grande passo em manter muitas cópias, mas ...

Acho que você se acostumou a todas as suas peculiaridades, ou não faz muita ramificação e fusão. Existe uma possibilidade pior;

As pessoas em sua organização se acostumaram às limitações do CVS e suas práticas de trabalho se adaptaram de acordo;

Por exemplo, nunca ter mais de um desenvolvedor trabalha em um pacote por vez, apenas usando ramificação em emergências etc.

O princípio básico é, quanto mais difícil é, menos as pessoas o fazem.

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