Subversion - SVN
O que é Subversion?
[editar | editar código-fonte]O Subversion (SVN) é um sistema de controle de versão open-source que gerencia arquivos e diretórios controlando as alterações realizadas ao longo do tempo. Além disso, é possível recuperar versões anteriores ou visualizar o histórico de alterações. Tem como ponto forte a utilização em rede, possibilitando que vários usuários possam trabalhar colaborativamente.
Permite que você recupere versões antigas de seus dados, ou que examine o histórico de suas alterações. É um sistema de caráter geral que pode ser usado para gerenciar quaisquer conjuntos de arquivos (código-fonte, arquivos de edição de vídeo, etc.)
O SVN utiliza o conceito de branches, tags e trunk:
- Trunk: pasta que contém os projetos que estão em desenvolvimento. Todas as atualizações efetuadas dia-a-dia são armazenadas nesta pasta.
- Branches: pasta que contém “linhas de desenvolvimento” de tal projeto, que entre elas pode haver poucas diferenças, porém uma independe da outra. Quando o projeto está pronto para ser liberado como uma versão estável, a pasta trunk é copiada para a pasta branch e dado um nome de versão. Este branch é congelado, não sofrendo mais alterações, apenas correções. Os testes são efetuados.
- Tags: quando os testes efetuados na branch estão completos, a versão que se encontra na branch é copiada para a pasta tags, criando a “release”. A pasta tag é empacotada e enviada para o cliente. Qualquer modificação em branch, deve ser copiada para a pasta de tags, após todos os testes. O SVN considera tag apenas uma variação de um branch, e na prática é exatamente como um branch, apenas uma cópia da ramificação atual da árvore.
Histórico
[editar | editar código-fonte]No início do ano de 2000 a empresa CollabNet, Inc iniciou um trabalho para a construção de um software de controle de versão utilizando o CVS como base. Em decorrência dos bugs e limitações do CVS, a CollabNet optou por iniciar a construção do zero.
Em fevereiro deste mesmo ano, a CollabNet entrou em contato com Karl Fogel, o autor do Open Source Development with CVS (Coriolis, 1999), para que ele pudesse participar deste novo projeto. Coincidentemente, Karl Fogel já estava discutindo um projeto de um novo sistema de controle de versão com Jim Blandy, juntos criaram em 1995 empresa Cyclic Software (empresa prestadora de contratos de suporte CVS) e apesar de terem vendido a empresa, eles ainda trabalhavam com o CVS em seus projetos. A partir dos problemas enfrentados, Jim começou a idealizar melhores soluções para gerenciar versões, idealizando inclusive o nome Subversion.
Assim, Karl Fogel foi trabalhar no projeto da CollabNet e Jim Blandy conseguiu uma licença de seu empregador para poder participar do projeto. O Subversion logo atraiu a comunidade de desenvolvedores e descobriu-se que muitos possuíam experiências frustrantes com o CVS.
A equipe do projeto original propôs o simples objetivo de manter os recursos do CVS, incluindo a sua arquitetura, mas sem os problemas constantes, facilitando a migração do CVS para o SVN.
O SVN começou a ser utilizado pelos desenvolvedores para gerir seu próprio código-fonte em 31 de agosto de 2001.
Um marco importante para o SVN foi a integração com o Apache Software Foundation (ASF), que iniciou em 2009.
No início de 2010, o Subversion foi totalmente adotado na família do ASF de projetos de nível superior, transferindo o projeto para http://subversion.apache.org, e foi rebatizado de "Apache Subversion".
Atualmente está na versão 1.9.3 lançada em dezembro de 2015.
Funcionalidades
[editar | editar código-fonte]- Versionamento de diretórios;
- Versionamento de renomeação, cópia e exclusão;
- Commits atômicos;
- Merge tracking;
- Bloqueio de arquivos;
- Resolução de conflitos interativos.
Instalando e configurando um Servidor Subversion no Debian
[editar | editar código-fonte]- Instalar o Subversion e o Apache
$ sudo apt-get install subversion libapache2-mod-passenger libapache2-svn apache2
- Adicionar ao Apache o local do SVN
$ sudo nano /etc/apache2/sites-avaible/default
Você pode visualizar todos os comandos em:
https://www.oficinadanet.com.br/post/9257-instalando-e-configurando-um-servidor-subversion-svn-no-debian
Principais Comandos
[editar | editar código-fonte]- Listar os comandos do SVN:
$ svn --help
- Adicionar diretório:
$ svn add directory
- Adicionar arquivo:
$ svn add arquivo
- Commitar arquivos ou diretórios locais no repositório SVN:
$ svn commit filename
$ svn commit --message "Message" filename
- Deletar arquivo do repositório:
$ svn delete filename
$ svn delete directory
- Bloquear arquivo para garantir acesso exclusivo:
$ svn lock filename -m "comment as to why its locked or by whom"
- Mostrar as mensagens do log do SVN:
$ svn log filename
- Mostrar status das mudanças em um arquivo:
$ svn status
- Trazer todas as atualizações do repositório SVN para sua cópia local:
$ svn update
O site youlinux.com disponibiliza um guia bem completo no que se refere a comandos e funcionalidades do Subversion:
http://www.yolinux.com/TUTORIALS/Subversion.html
Ferramentas de apoio
[editar | editar código-fonte]- Apache Subversion: versão oficial do Subversion;
- VisualSVN Server: implementação em Windows. É uma ferramenta prática e fácil de instalar o servidor SVN oficial. Possui um ambiente gráfico de gerenciamento e permite a visualização do conteúdo dos repositórios diretamente pelo navegador;
- TortoiseSVN: considerada a melhor ferramenta gráfica para utilização do SVN em ambiente Windows;
- RabbitVCS: ferramenta gráfica para utilização do SVN em Linux inspirada no TortoiseSVN;
- Commit Monitor: permite o recebimento de alertas a cada commit realizado nos repositórios SVN;
- CruiseControl e CruiseControl.NET: ferramentas de Integração Contínua.
Ferramenta Git SVN
[editar | editar código-fonte]O Git SVN é uma ferramenta permite utilizar o Git como um cliente válido para um servidor Subversion, possibilitando utilizar todos os recursos locais do Git e e fazer um push para um servidor Subversion, como se estivesse usando o Subversion localmente. Com esta ferramenta é possível fazer por exemplo ramificação (branching) local e fusão (merge), usar a área de teste (staging area), cherry-picking, etc.
Pode ser uma excelente opção em casos que a organização ainda não seja adepta ao Git, mas pode abrir portas para uma mudança futura.
O comando base no Git para todos os comandos relacionados ao Subversion é:
$ git svn
Configurando o Git SVN:
[editar | editar código-fonte]- Criar um novo repositório Subversion local:
$ mkdir /tmp/test-svn
$ svnadmin create /tmp/test-svn
- permitir que todos os usuários possam alterar revprops
$ cat /tmp/test-svn/hooks/pre-revprop-change
#!/bin/sh
exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
- Sincronizar este projeto na sua máquina local chamando svnsync init com os repositórios to e from.
$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
- Clonar o código executando:
$ svnsync sync file:///tmp/test-svn
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
...
- Permitir que todos os usuários possam alterar revprops — o caminho mais fácil é adicionar um script pre-revprop-change que sempre retorna 0:
$ cat /tmp/test-svn/hooks/pre-revprop-change
#!/bin/sh
exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
- sincronizar este projeto na sua máquina local chamando svnsync init com os repositórios to e from.
$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
- clonar o código:
$ svnsync sync file:///tmp/test-svn
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
...
Esta operação pode demorar apenas alguns minutos, porém se você tentar copiar o repositório original para outro repositório remoto em vez de um local, o processo vai demorar quase uma hora, independente se tem o não poucos committs. O Subversion tem que clonar uma revisão em um momento e logo depois fazer um push de volta para outro repositório. Não é muito eficiente, mas é a única maneira fácil de fazer isso.
Como o Git possui mais funcionalidades que o SVN, para que tudo ocorra bem, é importante segui as recomendações:
- Manter um histórico Git linear que não contém merge de commits realizados por git merge. Faça o rebase de qualquer trabalho que você fizer fora da sua branch principal (mainline) de volta para ela; não faça merge dela;
- Não colabore em um servidor Git separado. Eventualmente, tenha um para acelerar clones para novos desenvolvedores, mas não faça push de nada para ele que não tenha uma entrada git-svn-id. Você pode até querer adicionar um hook pre-receive que verifica cada mensagem de confirmação para encontrar um git-svn-id e rejeitar pushes que contenham commits sem ele.
- O Subversion pode ter apenas um histórico linear simples, e confundi-lo é muito fácil. Se você está trabalhando com uma equipe, e alguns estão usando SVN e outros estão usando Git, certifique-se que todo mundo está usando o servidor SVN para colaborar — isso vai facilitar a sua vida.
Referências
[editar | editar código-fonte]https://subversion.apache.org/
https://git-scm.com/book/pt-br/v1/Git-e-Outros-Sistemas-Git-e-Subversion
https://svnbook-pt-br.googlecode.com/svn/snapshots/1.4/svn.intro.whatis.html
http://intentor.com.br/svn-conceitos-boas-praticas-dicas-de-utilizacao/
https://www.oficinadanet.com.br/post/9257-instalando-e-configurando-um-servidor-subversion-svn-no-debian
https://samuca.wordpress.com/2007/04/12/tutorial-subversion/