CVS x SVN x Git

Fonte: Wikiversidade
Saltar para a navegação Saltar para a pesquisa

Introdução[editar | editar código-fonte]

CVS, ou Concurrent Version System (Sistema de Versões Concorrentes). SVN ou Apache Subversion e Git são todos sistemas de controle de versão de arquivos(VCS), livres para o uso, sendo primeiramente lançado o CVS, depois o SVN e por fim o Git. Existem alguns outros tipos de controle de versão disponíveis, como Mercurial e Bazaar, porém, nesse artigo, o foco será somente nos três supracitados, mostrando seus pontos principais e suas diferenças.

Conceitos Básicos[editar | editar código-fonte]

CVS[editar | editar código-fonte]

Com sua primeira release lançada em 1990, o CVS foi o primeiro sistema de controle versão disponível, criado por Dick Grune e posteriormente mantido pelo CVS Team. O CVS utiliza um sistema de versionamento centralizado, ou seja, ele possui um único servidor central que contém todos os arquivos versionados e vários usuários podem resgatar os arquivos do servidor.

Atualmente, o código do CVS é mantido por um grupo de voluntários.

SVN[editar | editar código-fonte]

Lançado em 2000, e com o desenvolvimento ativo até hoje, o SVN também é um VCS que utiliza uma arquitetura centralizada, como o CVS. Porém com ele se mostra um sistema mais robusto que o anterior, contando com commits atômicos e a possibilidade de renomear arquivos e diretórios livremente, além de outras funcionalidades.

Git[editar | editar código-fonte]

O Git, ultimo da comparação desse artigo, foi um VCS lançado na 3ª Geração de VCS's, a mesma em que se encontram Mercurial e Bazaar. O git foi desenvolvido por Linus Torvalds, criador do linux e possui arquitetura descentralizada, ou seja,  os clientes não apenas fazem cópias das últimas versões dos arquivos: eles são cópias completas do repositório. Assim, se um servidor falha, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo.

Instalação[editar | editar código-fonte]

CVS[editar | editar código-fonte]

$ sudo apt-get install cvs 

CVSD[editar | editar código-fonte]

O CVSD é um software de auxilio ao CVS que possibilita entre outros usos, a criação e configuração de usuários que não sejam usuários do sistema. Para mais informações visite, CVS.

SVN[editar | editar código-fonte]

$ sudo apt-get install subversion libapache2-mod-passenger libapache2-svn apache2
  • Adicionando no Apache o local do SVN
$ sudo nano /etc/apache2/sites-avaible/default

Git[editar | editar código-fonte]

$ sudo apt-get install git

PS: Todos os comando anteriores foram direcionados a sistemas debian.

Comandos Básicos[editar | editar código-fonte]

CVS[editar | editar código-fonte]

  • Inicializando um novo repositório:
 $ cvs init 
  • Importando um módulo para um repositório existente:
 $ cvs import modulo vendor_tag release_tag 

Módulo indica o módulo que deve ser criado no repositório, se este ainda não existir, vendor_tag geralmente indica o distribuidor ou autor do projeto e release_tag indica o marcador que deve ser usado durante a importação dos arquivos.

  • Realizando uma cópia de um módulo para um diretório existente:
 $ cvs checkout diretorio 
  • Atualizando os arquivos de um diretório de trabalho em relação ao conteúdo de um módulo do repositório:
 $ cvs update 
  • Adicionando um arquivo a um módulo:
 $ cvs add arquivo 
  • Removendo um arquivo de um módulo:
 $ cvs rm arquivo 
  • Enviando alterações de um diretório local para o repositório:
 $ cvs commit -m "Mensagem" nomeDoArquivo 

SVN[editar | editar código-fonte]

  • Criando um repositório:
 $ svnadmin create <nome_do_repositório_a_ser_criado> 
  • Adicionando arquivos ou diretórios:
 $ svn add <path> 
  • Removendo arquivos do repositório:
 $ svn rm <path_copia_local> 
  • Baixando uma cópia dos arquivos disponíveis no repositório:
 $ svn checkout <url_repositorio> 
  • Atualizando uma cópia local com a disponível no repositório:
 $ svn update <path> 
  • Listando os arquivos modificados na cópia de trabalho:
 $ svn status <path_repositorio> 
  • Enviando as alterações efetuadas na cópia local para o repositório:
 $ svn commit <path> -m <Mensagem> 

Git[editar | editar código-fonte]

  • Criando um novo repositório:
 $ git init
  • Obtendo um repositório existente:
 $ git clone /caminho/para/o/repositório 
  • Adicionando mudanças:
 $ git add arquivo 
  • Salvando mudanças localmente:
 $ git commit -m 'comentários da alteração' 
  • Enviando alterações ao repositório remoto:
 $ git push origin branch 
  • Se você não clonou um repositório existente e quer conectar seu repositório a um servidor remoto, você deve adicioná-lo com:
 $ git remote add origin <servidor> 
  • Atualizando repositório local:
 $ git pull 

Vantagens[editar | editar código-fonte]

CVS[editar | editar código-fonte]

A comparação do CVS com qualquer VCS atual é injusta, já que as funcionalidades e segurança que os sistemas atuais apresentam , mostram que o CVS já se tornou obsoleto. Portanto é possível afirmar que caso esteja procurando um VCS, o CVS não é a melhor opção, e que a unica situação na qual o CVS seria usado seria numa situação de legado em alguma organização.

SVN[editar | editar código-fonte]

Funciona muito bem para desenvolvedores individuais e pequenas equipes. Ele tem mecanismos mais práticos em fluxos de trabalho simples e que não costumam ter muito conflito.

Se destaca quando é exigido mais controle, principalmente em ambientes corporativos.

Vantagens[editar | editar código-fonte]

  • Permite travar arquivos impedindo atualizações.
  • Controle de privilégios de acesso mais sofisticados.
  • Commits Atômicos
  • Conceito de revisão.

Git[editar | editar código-fonte]

Um sistema descentralizado como o git se destaca quando o desenvolvimento é descentralizado, especialmente em equipes grandes com grande quantidade de atualizações e fluxos complicados. Porém o uso em equipes pequenas o uso também é possível e eficiente.

Uma diferença importante é que em sistemas distribuídos há uma distinção entre commit e push. O commit cria um snapshot local e só o push realmente manda as revisões pendentes para outro repositório. Em sistemas centralizados o commit faz tudo. Isto é mais simples mas cria dificuldades em ambientes de muitas atualizações por usuários diferentes.

Vantagens[editar | editar código-fonte]

  • Em quase tudo é executado mais rápido, em alguns casos muito mais rápido por ser otimizado para funcionar pela internet.
  • O repositório ocupa menos espaço.
  • É muito mais fácil administrar diversas fontes de atualizações.
  • É fácil trabalhar com cópias locais para fazer experimentos e desenvolvimentos paralelos. Branches são baratos e simples. São incentivados.
  • Incentiva o commit frequente.
  • Facilita muito fazer merge.
  • Permite trabalhar confortavelmente sem perder nenhuma funcionalidade e informação sem estar conectado ao servidor central (que pode e frequentemente é usado). Ele tem mais metadados locais.
  • Possui mais informações de auditoria e que permitem mais facilidades em toda a administração.
  • Manipula conversão de fim de linha mais facilmente.
  • As revisões são assinadas digitalmente.
  • A história do projeto pode ser modificada.
  • Possui uma staging area que permite selecionar partes que deseja enviar para um repositório.
  • Permite uma gama maior de fluxos de trabalho.

Principais Diferenças[editar | editar código-fonte]

CVS e SVN possuem um repositório central de onde os usuários fazem o checkout e commitdos artefatos versionados.

A vantagem dessa abordagem é que você pode ter um controle central sobre os projetos, impor segurança de acesso mais facilmente. Além disso, há a possibilidade de bloquear arquivos (lock).

Porém, existem muitas desvantagens. A principal delas é que esse tipo de sistema não escala muito bem, isto é, muitas equipes e projetos no mesmo repositório tendem a deixá-lo lento. Outra desvantagem importante é que os usuários não podem fazer muita coisa offline, sendo necessário sempre estar conectado ao servidor central para realizar operações como criar tagsbranches, fazer merge, etc.

Além disso, existem diferenças significativas entre CVS e SVN:

  • SVN consegue rastrear arquivos renomeados.
  • Se versionamento centralizado é lento, o CVS consegue ser mais ainda.
  • commit do CVS é por arquivo. Já o SVN consegue agrupar as mudanças de um commit, então é possível por exemplo voltar a uma revisão anterior. Isso facilita muito encontrar qual commit quebrou o código.

No Git não existe um repositório central. É claro que você pode eleger um como tal, mas cada repositório, mesmo o da máquina do desenvolvedor, contém uma cópia completa e funcional do repositório.

Uma desvantagem desse modelo é que a clonagem inicial do repositório pode demorar bastante, já que não será feita a transferência apenas da cópia atual de cada artefato, mas também do histórico, tags e branches. Algo que pode minimizar isso é a possibilidade de recuperar partes do repositório seletivamente, como branches, tags ou mesmo por data. Mas não sei de detalhes sobre até que ponto isso é implementado em cada um dos sistemas.

Outra desvantagem é a dificuldade de um gerenciamento centralizado e um controle de acesso efetivo, já que os repositórios ficam distribuídos em vários ambientes.

Além disso, nos sistemas de versionamento distribuídos, commit e checkout são feitos no repositório local de cada ambiente. Após a conclusão do trabalho, com a classe devidamente "commitada", tags "passadas" e "branches mergeadas", o desenvolvedor precisa sincronizar seu repositório local com o repositório remoto. Isso é feito com os comandos push (envia atualizações do seu repositório local para o remoto) e pull (recupera atualizações do repositório remoto para o local).

É um pouco mais complicado trabalhar com sistemas de versionamento distribuídos, mas as vantagens são muitas:

  • Exceto o pull inicial, eles são muito mais rápidos do que os sistemas centralizados como CVS e SVN.
  • Muitas operações não necessitam de acesso à rede, então o desenvolvedor pode trabalhar offline, sincronizando com o repositório remoto apenas quando necessário.
  • O desenvolvedor pode trabalhar em modo privado, gerando tags, branches e versões que serão simplesmente descartadas.
  • Exceto quando há conflitos, o merge é automático.
  • Cada cópia do repositório funciona como um backup