Apache Subversion - SVN e seus comandos principais

O Apache Subversion, conhecido como SVN, é um sistema de controle de versão e foi desenvolvido a partir do CVS com a proposta de corrigir suas limitações.

Dessa forma, o SVN funciona em quase tudo como o CVS, no entanto com acrescimentos de algumas outras funcionalidades. No SVN foram introduzidos os comandos rename e move, para corrigir os problemas relacionados a renomear e mover arquivos no CVS. Esses comandos não apenas renomeia/move o arquivo como mantém seu histórico de alterações. Diferente do CVS, no SVN o comando commit (de envio de arquivos) suporta rollbacks em caso de falhas. Além disso é possível também versionar arquivos não suportados pelo CVS, como links simbólicos. O SVN possui também capacidade de guardar metadados dos arquivos e diretórios.

SVN e CVS possuem basicamente os mesmos comandos, com exceção de alguns contidos apenas no SVN - como o comando move. Segue abaixo a lista dos principais comandos e sua descrição:

checkout

Ao executar este comando, o módulo (projeto) selecionado no repositório é baixado para o cliente.

add

Novos arquivos criados no módulo devem ser adicionados com este comando.

del

Remove o arquivo da próxima versão.

move

Renomeia ou move um arquivo no versionamento (deletando o antigo e adicionando o novo).


status 

Visualiza se um arquivo será ou foi adicionado, deletado, ou modificado localmente ou no repositório.

diff 

Visualiza as alterações feitas no arquivo.

log 

Visualiza a mensagem de commit do arquivo.

revert 

Reverte a alteração local feita no arquivo para a versão anterior.

update

Atualiza o módulo para a versão mais recente. Se houver alterações no mesmo arquivo, automaticamente é feito o merge - mescla ente ambos. Quando há conflitos, o arquivo é marcado e a mescla deve ser feita manualmente.

resolved 

Remove o status de conflito do arquivo.

commit 

Envia as alterações do módulo para o repositório central.

Referências

http://pt.stackoverflow.com/questions/8315/diferen%C3%A7as-entre-git-svn-e-cvs
http://pt.wikipedia.org/wiki/CVS
http://pt.wikipedia.org/wiki/Subversion
http://mariomariani.blogspot.com.br/2010/02/comandos-mais-usados-do-svn.html

Git ou Mercurial? parte 2

Um fato é que se considerarmos as funcionalidades e desempenho equivalentes (ou muito aproximados), a afinidade do Git ou Mercurial com as características da empresa/projeto/equipe se mostrarão mais importantes e desempatar será cada vez mais decidida por aspectos subjetivao como proximidade com outros projetos relacionados e preferência dos desenvolvedores.

Projetos Relacionados

Projetos maiores que já usam o Mercurial ou o Git acabam atraindo projetos relacionados para o seu campo de influência.

A interferência direta se dá quando é necessário acompanhar ou mesmo participar de certos projetos externos associados com o projeto da equipe. A escolha da mesma ferramenta para todos torna o controle de versão muito mais fácil pois define um padrão homogêneo.

A tabela a seguir apresenta alguns projetos e qual a ferramenta que usam.

Projeto	Git	Mercurial
Google Android	X
Google Code		X
Pylons		X
Python (linguagem)		X
Ruby on Rails	X
Sun (OpenJDK, NetBeans, OpenSolaris)		X

Preferência dos Desenvolvedores

Esse é o critério mais passional de todos. O que leva um desenvolvedor a preferir uma ferramenta a outra varia desde a identificação com a filosofia do projeto até a preferência pelo logotipo do projeto. De qualquer modo, uma tendência clara da equipe por uma ferramenta específica deve ser pesado na decisão final.

Estudos de Caso

	Projeto X	Projeto Y	Projeto Z
Escolha Final	Mercurial	Git	Mercurial
Plataforma	Windows	Windows/Linux	Linux
IDE/Interface	Eclipse	NetBeans	linha de comando
Linguagem Principal	Java	Ruby	Python
Projetos relacionados usam	Subversion/Mercurial	Git	Subversion/Mercurial
Preferência dos Desenvolvedores	-	Git	Mercurial

Considerações Finais

Git e Mercurial são ambas ótimas opções de controle de versão distribuído. A análise de um ou outro baseado em número de funcionalidades, forma de implementação interna, desempenho etc. acaba caindo em um tipo de discussão que abunda pelas listas de discussão na internet a fora e que gera muito calor e pouca luz!

Em termos práticos, ambas as ferramentas são muito parecidas e é mais fácil (e prático) escolher entre uma e outra com base na afinidade com o projeto/equipe.

É bom lembrar que controle de versão é muito mais que instalar a ferramenta e sair usando. É necessária a capacitação dos desenvolvedores, a definição de um processo de GCS em sintonia com as particularidades da ferramenta e também integração com uma ferramenta de controle de mudança (por exemplo, o Trac).

Git ou Mercurial? parte 1

Conhecemos os dois tipos de controles de versão: o centralizado e o Distribuído e levando em consideração isso devemos analisar a partir de alguns critérios qual seria a melhor ferramenta para as equipes que decidiram migrar para o distribuído ou mesmo permanecer com o centralizado.

Para quem vai ficar no controle de versão centralizado, é bem simples decidir já é o Subversion é um padrão estabelecido, acima de outros tais como CVS, Visual Source Safe, ClearCase etc.
Já para os que optaram por escolher uma ferramenta de controle de versão distribuído, a escolha é um desafio.

Para diminuir o número inicial de ferramentas a se considerar, vamos usar alguns critérios de filtragem inicial:

Open source.

As melhores são open source então não há a menor necessidade de usar uma ferramenta proprietária para controle de versão.

Multiplataforma (Windows, Linux, etc.).

A mesma ferramenta deve permitir o uso de qualquer plataforma de interesse da a equipe para trabalhar. Se houver interface gráfica (tipo o Tortoise) ou plugin para IDEs é ainda melhor, mesmo que a linha de comando seja muito mais rápida e produtiva para a maioria das operações do controle de versão.

Massa crítica de projetos já usando.

Projetos grandes usando uma ferramenta são boas referências, sinaliza que ela já foi testada, avaliada e aceita por outros antes. Com mais projetos fica mais provável que haverá uma comunidade ativa mantendo e desenvolvendo a ferramenta por mais tempo.

Após usar esses critérios acima, nos restam praticamente o Git e o Mercurial. O Bazaar poderia entrar na lista, mas para facilitar a comparação não o incluímos(com resultados piores que os outros 2 e não tão popularizado). Muitos outros como Darcs, Monotone e SVK não passam no critério 3.
A seguir, alguns projetos conhecidos que usam o Mercurial ou o Git:

Mercurial:

[2]

e mais: Google Code, Python, OpenSolaris etc.

Git: 

• [2]

e mais, Perl, Samba, Qt, Btrfs da Oracle etc.

Aspectos Sociais na Escolha do DVCS

"Critérios de desempate podem ser desempenho, funcionalidades, facilidade de uso, portabilidade, interfaces etc. O problema é que as análises comparativas entre o Mercurial e o Git têm mostrado muito mais semelhanças que diferenças entre os dois. Embora um ou outro tenha uma pequena vantagem em algum dos aspectos, não há diferença realmente significativa que justifique uma decisão baseado nisso.

Novos processos tem se apoiado em outros fatores de desempate, suporte à plataforma Windows, preferência dos desenvolvedores envolvidos e menor curva de aprendizado da ferramenta."[1]

2 exemplos de escolhas fundadas no aspecto social:

O Google Code fez uma análise comparativa entre o Mercurial e o Git considerando as duas alternativas bastante equilibradas e escolheram o Mercurial seu conjunto de comandos ser mais próximos do Subversion, o que facilita a transição dos desenvolvedores, e pelo serviço que o Google Code já oferece ter tido melhor desempenho e adequação com o Mercurial do que o Git.

O processo que levou o Python a também adotar o Mercurial (PEP 374 – Chosing a distributed VCS for the Python project) comparou Mercurial, Bazaar e Git e apresentou comparações de desempenho obtido, alguns casos de uso, mas as características que favoreceram o Mercurial foram: seu melhor suporte ao Windows, a preferência da comunidade de desenvolvedores pelo Mercurial e, o fato de o Mercurial ser escrito em Python , que facilitou a assimilação da ferramenta.

Fontes 

1- Blog Pronus - Qual a melhor ferramenta de controle de versão: Subversion, Git ou Mercurial. Comparação entre Git e Mercurial principalmente considerando fatores socias para a escolha.
2 - Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar. Boa apresentação em slides comparando as 3 ferramentas exibindo dados e tabelas interessantes. 

Links relacionados

Comparação entre Git e Mercurial. Quadro comparativo entre principais características entre os dois. Alguns comentários interessantes também sobre portabilidade e interfaces disponíveis.
Why Git is better than X? Artigo interessante que analisa diversos pontos de Git com boas ilustrações de conceitos.
Os 6 melhores controle versões OpenSource. Bom comparativo entre sistemas de controle de versão.
PEP 374 – Chosing a distributed VCS for the Python project.Google Code - análise comparativa Mercurial e Git.

Funcionamento do CVS

Como Funciona

O CVS funciona a partir da arquitetura cliente-servidor. Nesta arquitetura, um servidor armazena as versões do projeto e os usuários envolvidos se conectam ao servidor para acessar, fazer cópia e atualizar o projeto, neste caso, se comportando como clientes. Cliente e servidor podem se conectar através de uma rede local ou Internet. É também possível que cliente e servidor estejam na mesma máquina, caso a configuração do CVS seja feita de maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. Um servidor CVS deve estar em um Sistema Operacional Unix (ou Linux), no entanto não há restrições para o cliente.

Os projetos gerenciados pelo CVS são chamados de módulos. Os módulos são acessados e modificados de maneira concorrente por um grupo de usuários que trabalham em equipe. Quando alterações são feitas e confirmadas - através do comando commit - o servidor ao ser atualizado - com o comando update - faz uma mescla do projeto atual com o que há de novo. A mescla é feita através do merge. No entanto, se houver conflito entre arquivos modificados - quando há, por exemplo, modificações diferentes feitas na mesma região de um arquivo - o merge é abortado e o servidor avisa que existe algum conflito e que é necessário uma intervenção humana. Caso contrário, a versão é incrementada e o servidor CVS escreve uma linha de observação com data e o autor das alterações em seus arquivos de log - além de observações informadas pelo próprio usuário, quando houver.

Entre as funcionalidades disponíveis aos usuários clientes estão a capacidade de comparar diferentes versões de um arquivo, pedir um histórico completo das alterações ou baixar uma determinada versão do projeto - a partir de uma data ou de uma das alterações no histórico, por exemplo. Para manter suas cópias locais atualizadas com a última versão do servidor os clientes utilizam o comando update.

No repositório existem 3 tipos de diretório: trunk, branches e tags. O trunk mantém o fluxo principal de desenvolvimento. Já o branches mantém os fluxos alternativos de desenvolvimento, como novas ramificações a partir de uma determinada versão. Por último, em tags ficam registradas revisões que não podem mais serem alteradas, ou seja, versões estáveis do projeto.

Limitações

As maiores limitações do CVS estão relacionadas a impossibilidade de mover e renomear arquivos sem perder sua referência e seu histórico de alterações. Quando necessário renomear um arquivo, este deve ser explicitamente removido e novamente adicionado com seu novo nome. Para mover ou renomear diretórios são enfrentados os mesmos problemas, dessa forma, cada arquivo do subdiretório em questão deve ser individualmente removido e readicionado.

O Apache Subversion (SVN), criado como substituto do CVS, corrige essas falhas.

Referências

http://www.embarcados.com.br/controle-de-versoes-parte-ii-cvssvn/
http://www.devmedia.com.br/cvs-instalacao-e-configuracao/2801
http://pt.wikipedia.org/wiki/CVS

Mercurial, Eu escolho você!

Nome

O nome “mercurial” é um adjetivo que significa “Relativo a ou que tenham características (eloquência, rapidez, inteligência) atribuído ao deus Mercúrio.”

O que é?

Mercurial é um sistema de controle de versão de distribuição open-source (o Mercurial é disponibilizado como Software livre nos termos da licença GNU GPL v2 e versões em diante), assim como CVS, Subversion e Git, etc. Diferente do CVS e Subversion, o Mercurial é uma ferramenta multi-plataforma que se baseia em repositórios distribuídos como o Git, não havendo dependência do acesso ao repositório central para as transações de versionamento ocorrerem.

A descentralização é alcançada no Mercurial pois o sistema implementa repositórios locais que contém todo o histórico dos dados que ele versiona. Para os familiares ao funcionamento do Subversion, seria como se cada checkout se tornasse um repositório local contendo todo o histórico das transações anteriores e permitindo ao usuário a realização de commits, reverts, etc, localmente, permitindo a integração deste novo repositório ao repositório central a qualquer momento. 

Características

Muito bom para grandes projetos

Esse sistema foi concebido para projetos maiores, de difícil alcance para desenvolvedores independentes ou web designers mais provalvelmente, mas não significa que para equipes pequenas de desenvolvimento não seja possível usá-lo, visto que o Mercurial é extremamente rápido, e com o desempenho como a característica mais importante.

Fácil adaptação para desenvolvedores de outros CVS

Além de muito rápido e escalável, o Mercurial é um sistema muito mais simples do que Git. Não há até o momento muitas funções para aprender, e essas se asemelhantes às de outros sistemas CVS. Ele também vem equipado com uma interface Web stand-alone e contem extensa documentação sobre como compreender o Mercurial se você estiver utilizando um outro sistema, o que facilita a adaptação dos desenvolvedores.

Implementação

O sistema é implementado principalmente em Python, porém o utilitário binário diff foi escrito em C. Mercurial foi inicialmente escrito para rodar sobre Linux, mas foi portado para Windows, Mac OS X, e a maioria dos outros sistemas UNIX. Ele é principalmente um programa de linha de comando, todas operações do Mercurial são chamadas através de palavras chave de opções para o programa controlador hg, uma referência para o símbolo químico do elemento Mercúrio.

Principais objetivos de sua concepção

O criador e desenvolvedor líder do Mercurial é o Matt Mackall e os objetivos principais no desenvolvimento do Mercurial incluem alta performance e escalabilidade, descentralização, desenvolvimento colaborativo distribuído, controle de arquivos textuais e binários de forma robusta, e operações avançadas de ramos (branches) e mesclagem (merges). Mercurial também inclui de forma integrada um sistema de visualização dos repositórios via web e facilitação na transição de usuários do Subversion.

Conclusão

Concluímos sobre o sistema de versionamento Mercurial, que este oferece algumas vantagens significativas para a sua implantação e uso em equipes de desenvolvimento. Essas vantagens se apoiam nas características do Mercurial que incluem aspectos como: adaptação de desenvolvedores de outros CVS, portabilidade, ser multiplataforma, velocidade e robustez, customização para desenvolvedores Python, poucos comandos, interface web stand-alone,  aprendizado facilitado e documentação extensa ja incluída no pacote de distribuição que é open-source.

Fontes 

1 - Os 6 melhores controle versões OpenSource Post que mostra deficições e caracteristicas interessantes de 6 sistemas de controle de versão escolhidos pelo autor.
2 - Simples Consultorias - Mercurial HG Conteúdo introdutório de instalação e configuração do Mercurial.

Links relacionados:

Mercurial tutorial – Tutorial sobre como instalar e trabalhar com Mercurial.
Lista de ferramentas GUI para Mercurial – Ferramentas para uso com qualquer plataforma de trabalho com Mercurial.
Compreender Mercurial – Documento explicando o que faz e não faz.
Use Mercurial, Git você! – Artigo mostrando porque o Mercurial é melhor que Git.

História do Git

Git é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte com ênfase em velocidade. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos.

O desenvolvimento do Git surgiu após vários desenvolvedores do kernel (núcleo) do Linux decidirem desistir de acessar ao sistema do BitKeeper, que é um software proprietário. O acesso gratuito ao BitKeeper foi removido pelo detentor dos direitos autorais, Larry McVoy, depois de acusar Andrew Tridgell de usar de engenharia reversa nos protocolos do BitKeeper, alegando violação da licença.

Torvalds queria um sistema distribuído que ele pudesse utilizar de forma similar ao BitKeeper (BK), mas nenhum dos sistemas gratuitos disponíveis atendia suas necessidades, particularmente com relação à performance. Segue abaixo uma parte retirada de um e-mail, de 7 de Abril de 2005, escrito enquanto desenvolvia seu primeiro protótipo:

De qualquer forma, os SCVs que olhei dificultam as coisas. Uma delas (a maior delas, na verdade) que estive trabalhando é fazer este processo ser realmente eficiente. Se leva meio minuto para aplicar um patch e ainda lembrar o que mudou, etc (e francamente, isso é rápido para a maioria dos SCVs por aí para um projeto do tamanho do Linux), daí uma série de 250 e-mails (que não é estranho acontecer quando eu sincronizo com o Andrew, por exemplo) demora duas horas. Se um dos patches no meio do processo não é aplicado, as coisas ficam realmente muito feias.
Agora, o BK (BitKeeper) não era um inferno também (na verdade, comparado com todo o resto, o BK é um inferno em velocidade, geralmente em uma ou duas ordens de magnitude), e levou cerca de 10-15 segundos por e-mail quando mesclei meus arquivos com o Andrew. MESMO ASSIM, com o BK isso não era um problema tão grande, visto que mesclas de arquivos de BK←>BK eram tão fáceis, eu nunca precisei das lentas mesclas por e-mail com nenhum dos outros desenvolvedores principais. Então um "mesclador" de um SCV baseado em patches precisaria ser realmente mais rápido que o BK. O que realmente é extremamente difícil.
Então eu estou escrevendo alguns scripts para tentar alinhar tudo mais rápido. Indicações iniciais são de que eu poderei fazer isso tão rápido quanto eu aplico patches, mas para ser franco, estou no máximo com metade pronto, e se eu estiver na direção errada, talvez essa não seja a mais pura verdade. De qualquer forma, a razão de que eu consigo criar tudo isso tão rápido é que meus scripts não serão um SCV, serão tipo um "registro de estado do Linus" bem específico. Isso vai fazer minhas mesclas lineares de patches muito mais eficientes no tempo, e nestas condições, possível.
(Se a aplicação de um patch demora três segundos, até mesmo uma série grande de patches não é um problema: se eu for notificado em um minuto ou dois que falhou na metade do caminho, sem problemas, eu posso então simplesmente arrumar manualmente. É por isso que a latência é crítica - se eu tivesse que fazer as coisas efetivamente "desconectado", eu não poderia, por definição, arrumar as coisas quando problemas aparecessem).

Torvalds teve vários critérios para o projeto:

• Tomar o CVS como um exemplo do que não fazer; na dúvida, tomar exatamente a decisão contrária:

"Nos primeiros 10 anos de manutenção do kernel, nós literalmente usamos patches de tarballs, o que é muito superior como controle de versão que o CVS, mas eu acabei usando o CVS por 7 anos em uma empresa comercial [Transmeta7 ] e eu odiava de paixão. Quando eu digo que eu odiava de paixão, eu também tenho que dizer que, se houver algum usuário de SVN (Subversion) na platéia, talvez você queira sair. Porque meu ódio pelo CVS significa que eu vejo o Subversion como sendo o projeto iniciado mais sem objetivo de todos os tempos. O slogan do Subversion por um tempo foi "CVS feito [do jeito] certo", ou algo assim, e se você começa com esse slogan, você não vai a lugar nenhum. Não tem como o CVS fazer [do jeito] certo."

• Suportar um fluxo distribuído, como o BitKeeper:

"O BitKeeper não foi simplesmente o primeiro sistema de versionamento que eu senti que absolutamente valia a pena, foi também o sistema de controle de versão que me ensinou porque eles tem um objetivo, e como você realmente deve fazer as coisas. Então o Git, de várias formas, mesmo que de uma visão técnica muito diferente do BitKeeper (e isso foi outro objetivo de projeto, porque eu queria deixar claro que não era um plágio do BitKeeper), muitos dos fluxos que usamos no Git vieram diretamente dos fluxos que aprendemos com o BitKeeper."

• Várias firmes proteções contra corrompimento de arquivos, seja por acidente ou origem maldosa;
• Alta performance.

O desenvolvimento do Git começou em 3 de Abril de 2005. O projeto foi anunciado em 6 de Abril e tornou-se auto-hospedeiro no dia 7 de Abril. A primeira mescla de arquivos (merge) em múltiplos ramos (branches) foi realizado em 18 de Abril. Torvalds alcançou seus objetivos de performance; em 29 de Abril, o recém-nascido Git se tornou referência ao registrar patches para a árvore de desenvolvimento do kernel do Linux na taxa de 6,7 por segundo. No dia 16 de Junho, a entrega do kernel 2.6.12 foi gerenciada pelo Git.

Mesmo que fortemente influenciado pelo BitKeeper, Torvalds deliberadamente tentou evitar abordagens tradicionais, levando a um design único. Ele desenvolveu o sistema até que fosse possível sua utilização por usuários técnicos, entregando então a manutenção do software para Junio Hamano, um dos principais colaboradores do projeto, em 16 de Julho de 2005. Hamano foi responsável pela entrega da versão 1.0 em 21 de dezembro de 2005 e continua como responsável pela manutenção do mesmo.

Sobre o CVS

O CVS (Concurrent Version System - Sistema de Versões Concorrentes) é um sistema de controle de versão baseado na arquitetura cliente-servidor. Ele permite que diferentes usuários trabalhem de maneira paralela em um mesmo projeto, simplificando o processo de modificação, atualização e auditoria do projeto desenvolvido em equipe ao gerenciar, a partir de um repositório, todas as alterações realizadas, mantendo históricos de modificação e logs - contendo, por exemplo, datas e informações sobre os usuários responsáveis.

O CVS foi desenvolvido a partir de um sistema chamado Revision Control System (RCS), ainda em uso, que gerencia versões de arquivos únicos. Dick Grune escreveu em seu site sobre a criação do CVS:

Criei o CVS para poder cooperar com meus alunos Erik Baalbergen e Maarten Waage no ACK (Amsterdam Compiler Kit) Compilador C. Cada um de nós tinha uma rotina diferente (um dos alunos trabalhava 45h por semana, outro era irregular e eu podia trabalhar no projeto apenas à noite). O projeto deles durou de Julho de 1984 até Agosto de 1985. O CVS foi chamado inicialmente de CMT, pela razão óbvia que nos permitia validar (commit) versões independentemente.

A versão atual do CVS foi iniciada por Brian Berliner no ano de 1989, recebendo posteriormente contribuição de mais pessoas. O CVS foi usado pelo Prisma, uma equipe de desenvolvimento do Sistema Operacional SunOS (primeiras versões do Solaris). 

Em favor da comunidade GPL, o CVS foi lançado em código aberto e seu download pode ser feito gratuitamente. Atualmente, o código do CVS é mantido por um grupo de voluntários.

Referências

http://pt.stackoverflow.com/questions/8315/diferen%C3%A7as-entre-git-svn-e-cvs
http://www.embarcados.com.br/controle-de-versoes-parte-ii-cvssvn/
http://pt.wikipedia.org/wiki/CVS

http://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%A3o