Ferramentas de Usuário

Ferramentas de Site


revistaprogramar_arquivo:18_edicao:capa2

Subversion: Controlo Total sobre o Software - 2.ª Parte

Nesta 2.ª parte do artigo sobre Subversion (a 1.ª parte encontra-se na edição n.º 17), vamos ver como deveremos usar o Subversion no dia-a-dia e também algumas das ferramentas que existem actualmente e que se integram bastante bem com o Subversion. Com estas ferramentas poderemos tirar mais partido do Subversion, uma vez que nos vão fornecer um conjunto de funcionalidades acrescidas (entre as quais: disponibilidade do código online, autenticação e autorização no repositório, gestão das alterações feitas a cada revisão, facilidade em aferir as diferenças entre as modificações feitas numa cópia local de trabalho e o repositório central de código), como veremos em seguida.

No fim deste artigo apresenta-se bibliografia recomendada para quem desejar extender os seus conhecimentos sobre este sistema de controlo de versões de software, cada vez mais utilizado hoje em dia.

Ciclo Normal de Trabalho com SVN

Checkout Inicial

Na maior parte das vezes, começa-se a usar um repositório de Subversion fazendo um checkout ao projecto em questão. Ao fazer isto, é criada na máquina local uma cópia do projecto. Esta cópia contém a HEAD (última revisão) do repositório SVN que é especificado na linha de comandos:

$ svn checkout http://svn.exemplo.pt/repositorio/trunk
A  trunk/subversion.dsw
A  trunk/svn_check.dsp
A  trunk/Makefile
A  trunk/configure
A  trunk/ficheiroA.c
...
Checked out revision 327.

Apesar do exemplo acima fazer checkout da directoria /trunk, pode-se igualmente escolher uma subdirectoria do repositório ao especificar o subdirectório no URL:

$ svn checkout http://svn.exemplo.pt/repositorio/trunk/documentacao/pdfs
A   trunk/documentacao/pdfs/faq.pdf
A   trunk/documentacao/pdfs/userguide.pdf
A   trunk/documentacao/pdfs/manual-de-instalacao.pdf
...
Checked out revision 327.

Uma vez que o Subversion usa o modelo copia-modifica-unifica em vez do modelo bloqueia-modifica-desbloqueia, o utilizador pode logo começar a fazer alterações aos ficheiros e directorias na sua cópia de trabalho. Esta cópia de trabalho é igual a qualquer outra colecção de ficheiros e directorias no computador. O utilizador pode editar e alterar os ficheiros, navegar e mover pastas, ou até mesmo apagar a cópia de trabalho inteira e trabalhar numa nova. Apesar de realmente ser uma colecção de ficheiros e directorias como qualquer outra, é preciso sempre avisar o Subversion se se quiser re-arranjar qualquer ficheiro ou directoria dentro da cópia de trabalho. Por isso, deve-se sempre usar os comandos svn copy ou svn move em vez dos comandos normais (Ctrl-C ou Ctrl-X, por exemplo) para que essas alterações sejam reflectidas a todos os utilizadores quando fizerem um svn update nas suas cópias de trabalho.

Cada directoria na cópia de trabalho local contém uma área administrativa, uma sub-directoria chamada .svn. Normalmente, um comando de listagem de directórios não mostra esta sub-directoria, mas é no entanto uma directoria muito importante que não se deve nunca apagar ou alterar. O Subversion depende desta directoria para gerir a cópia de trabalho de cada utilizador.

Pode-se também fazer um checkout especificando uma nova directoria que vai passar a ser a nova cópia de trabalho depois do URL do repositório, nos parâmetros do comando de checkout:

$ svn checkout http://exemplo.efacec.pt/repositorio/trunk/documentacao/pdfs directoriaNova
A   directoriaNova/faq.pdf
A   directoriaNova/userguide.pdf
A   directoriaNova/manual-de-instalacao.pdf
...
Checked out revision 327.

Isto coloca a cópia de trabalho numa directoria chamada directoriaNova em vez da directoria trunk como tínhamos visto previamente.

Ciclo normal de trabalho

O Subversion tem bastantes funcionalidades, opções, possibilidades de uso, mas para uma utilização diária só se irá usar um sub-conjunto limitado das funcionalidades do Subversion. O ciclo de trabalho é tipicamente o seguinte:

  • Fazer um update à cópia de trabalho
    • svn update
  • Fazer as alterações necessárias aos ficheiros da cópia de trabalho
    • svn add
    • svn delete
    • svn copy
    • svn move
  • Examinar as alterações feitas
    • svn status
    • svn diff
    • svn revert
  • Unificar as alterações feitas por outros utilizadores na cópia de trabalho local
    • svn update
    • svn resolved
  • E por fim, e só agora, fazer uma submissão das alterações feitas na cópia de trabalho local para o repositório de SVN
    • svn commit

O diagrama seguinte exemplifica melhor o ciclo normal de desenvolvimento com o Subversion.

Propriedades do Subversion

O Subversion permite criar propriedades com versão nos ficheiros e directorias (com os nomes que se quiser), bem como propriedades sem versão nas revisões. A única restrição encontra-se nas propriedades com o prefixo svn: que são propriedades reservadas ao Subversion nesse espaço de nomes (namespace). Enquanto que as propriedades fora deste espaço de nomes podem ser usadas para controlar o comportamento do Subversion, os utilizadores não podem criar ou alterar propriedades do espaço de nomes svn:. Estas são:

  • Propriedades com versão
    • svn:executable - Se está presente num ficheiro, o cliente de SVN fará o ficheiro executável em cópias de trabalho em ambiente Unix; Em ambiente Windows, para ser executável basta ter a extensão .exe ou .bat.
    • svn:mime-type - Se está presente num ficheiro, o valor indica o tipo MIME do ficheiro. Isto permite ao cliente de SVN decidir se uma fusão (merging) contextual é possível de ser feita durante um update, e pode também afectar como o ficheiro se comporta quando é procurado via web browser;
    • svn:ignore - Se está presente numa directoria, o valor é uma lista de padrões de ficheiros sem versão a serem ignorados pelo subcomando svn status ou outros; Por exemplo, "*.log *.dmp core.*";
    • svn:keywords - Se está presente num ficheiro, o valor diz ao cliente de SVN como expandir palavras-chave (keywords) particulares dentro do ficheiro;
    • svn:eol-style - Se está presente num ficheiro, o valor diz ao cliente de SVN como manipular o fim de uma linha no ficheiro na cópia de trabalho; Por exemplo, CRLF (em Windows) ou CR (em Unix/Linux);
    • svn:externals - Se está presente numa directoria, o valor é uma lista com vários caminhos (paths) e URLs a que o cliente de SVN deverá fazer checkout; Esta propriedade é muito útil quando se precisa de usar código-fonte de terceiras fontes mas que não precisamos que estejam versionadas no repositório de SVN;
    • svn:special - Se está presente num ficheiro, indica que o ficheiro não é um ficheiro normal, mas um link simbólico ou outro tipo especial de objecto;
    • svn:needs-lock - Se está presente num ficheiro, indica ao cliente de SVN para colocar o ficheiro só para leitura na cópia de trabalho, como uma nota de que esse ficheiro deverá ser bloqueado (locked) antes da sua edição (para desta forma ganhar propriedades de escrita e garantir que só um utilizador pode alterar esse ficheiro).
  • Propriedades sem versão
    • svn:author - Se está presente, contém o nome do utilizador autenticado que criou a revisão (se não estiver presente, a revisão foi feita anonimamente);
    • svn:date - contém o tempo UTC em que a revisão foi criada, no formato ISO. O valor vem do relógio do servidor;
    • svn:log - contém a mensagem de log que descreve a revisão; Esta mensagem pode ser alterada após um commit, caso hajam enganos na mensagem que se queria ter colocado no commit;
    • svn:autoversioned - Se está presente, a revisão foi criada com a funcionalidade de versionamento automático.

URLs dos repositórios Subversion

Os repositórios de Subversion podem ser acedidos através de vários métodos – localmente no disco (directamente) ou através de vários protocolos de rede (indirectamente). A localização de um repositório, no entanto, é sempre um URL. Em seguida apresenta-­se uma tabela que descreve como os diferentes URLs mapeam os diferentes métodos de acesso a um repositório Subversion.

Esquema Método de acesso
file:// Acesso directo ao repositório (disco local).
http:// Acesso via protocolo WebDAV para o servidor Apache do Subversion
https:// O mesmo que para http:, mas com encriptação SSL (mais seguro)
svn:// Acesso via protocolo svn a um servidor a correr svnserve
svn+ssh:// O mesmo que svn:, mas através de um túnel SSH
Se se usar o SVN em DOS, as barras devem ser como numa directoria em Linux (/) e não da forma nativa ().Exemplo: file:///repositorio/pasta/ e não file:///repositoriopasta

Ajuda do SVN

Um dos mais importantes comandos do SVN é o svn help. A qualquer momento, um

svn help sub-comando

descreve a sintaxe, os switches que podem ser usados e o comportamento normal desse sub-comando.

Instalação do SVN

Instalação em Linux (distribuição Ubuntu)

A instalação do subversion em Ubuntu é extremamente simples e funcional. Basta fazer numa linha de comandos:

sudo apt-get install subversion libapache2-svn

Instalação em Windows (TortoiseSVN)

A instalação em Windows pode ser feita de duas maneiras: instalando os binários do cliente/servidor de SVN (e passa-se a usar apenas o subversion numa shell DOS, o que não é muito interessante para os utilizadores do Windows), ou instala-se um cliente gráfico para Windows: um dos melhores actualmente é o TortoiseSVN. Vejamos a seguir como instalar o TortoiseSVN (apenas para Windows):

  1. Descarregar o TortoiseSVN no site oficial de downloads;
  2. Duplo-clique no instalador .msi e resta apenas seguir as instruções apresentadas;
  3. Um reboot será necessário para o TortoiseSVN ser correctamente instalado.

Uma das principais vantagens de uso do TortoiseSVN é a integração que tem no Windows explorer (clique no botão direito do rato faz surgir no menu de contexto as opções do TortoiseSVN) independentemente de outros clientes gráficos que estejamos a usar. Outra grande vantagem é a sobreposição de ícones no Windows: nas pastas que sejam de cópias locais de trabalho SVN, os ícones das pastas e dos ficheiros são alterados para indicar visualmente o estado da cópia local de trabalho; em suma, o programador vê instantaneamente o estado da sua cópia local de trabalho sem necessitar de fazer um svn status, o que é realmente muito bom.

Componentes do Subversion

Uma vez instalado o Subversion, temos uma série de diferentes componentes deste software ao nosso dispôr:

  • svn: o programa cliente de linha de comandos;
  • svnversion: o programa para reportar o estado (em termos das revisões do software) de uma cópia de trabalho;
  • svnlook: a ferramenta para inspeccionar o estado de um repositório de Subversion;
  • svnadmin: a ferramenta para criar, alterar ou reparar um repositório de Subversion;
  • svndumpfilter: o programa para filtrar os dump streams do Subversion;
  • mod_dav_svn: um módulo de plugins para o servidor HTTP da Apache, usado para colocar o repositório disponível a outros utilizadores através de uma rede;
  • svnserve: um programa servidor, que corre como um processo (daemon) ou pode ser também invocado via SSH; é outra forma de tornar o repositório disponível a outros utilizadores através de uma rede, através do protocolo svn, em vez de se usar o servidor HTTP da Apache.

Configuração do servidor de HTTP Apache

Nesta secção vamos ver como configurar o servidor HTTP da Apache para usar URLs que pertençam a repositórios SVN, usufruindo deste modo da autenticação e autorização fornecidos por este servidor. Os passos que se seguem são para Linux (distribuição Ubuntu), mas para Windows é em tudo semelhante (os comandos para criar e popular um repositório podem ser todos feitos recorrendo ao TortoiseSVN).

Vamos começar por criar um repositório:

$ svnadmin create /home/projecto/ProjX
$ ls /home/projecto/ProjX
conf/  dav/  db/  format  hooks/  locks/  README.txt

Neste momento temos um repositório SVN para o ProjX, mas que está vazio, sem ficheiros. Para popular o repositório com ficheiros, teremos que ter outra pasta que tem todos os ficheiros que queremos adicionar ao projecto SVN:

$ ls -F /tmp/ProjX
trunk/ tags/ branches/
$ ls -F trunk
pasta1/ pasta2/ README.txt CHANGELOG ficheiro1.c ficheiro1.h

Esta pasta /tmp/ProjX tem todo o código que vamos querer importar para o repositório. Depois disso, podemos apagar esta pasta, pois todo o seu conteúdo já estará no repositório SVN. Resta portanto, importar o conteúdo desta pasta para o nosso repositório SVN:

$ svn import /tmp/ProjX file:///home/projecto/ProjX -m "import inicial"
Não colocar / no fim dos caminhos (é /tmp/ProjX e não /tmp/ProjX/; o mesmo para o segundo caminho indicado); O nome para o projecto, neste caso ProjX, deverá ser coincidente nos dois caminhos apresentados.
Em Windows, estes comandos para criar e popular um repositório são facilmente reproduzidos com o TortoiseSVN, carregando com o botão direito do rato para aceder às opções de criar um repositório e importar dados.

Depois de importar os dados com sucesso, vamos transferir o conteúdo de ProjX para uma cópia local de trabalho:

$ svn checkout file:///home/projecto/ProjX/trunk nome-do-projecto
 
 
A  nome-do-projecto/pasta1
A  nome-do-projecto/pasta2
A  nome-do-projecto/README.txt
…
Checked out revision 1.
No checkout, o nome para a pasta local que vai conter o ProjX é o que o utilizador pretender, não tem de ser igual a ProjX.

Resta apenas configurar o servidor HTTP da Apache. Aceder ao ficheiro de configuração, apache2.conf, que fica em /etc/apache2 e adicionar as entradas:

Em versões anteriores à 2.2 do servidor HTTP da Apache, o ficheiro apache2.conf é substituído pelo ficheiro httpd.conf
LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so

(na secção inicial de carregamento dos módulos)

<Location /ProjX>
  DAV svn
  SVNPath /home/projecto/ProjX
</Location>

(na secção das Locations; Neste caso, URLs do tipo http://localhost/ProjX vão ser tratados pelo Apache para carregar com o módulo dav_svn o conteúdo do projecto ProjX.)

Reiniciamos o apache:

sudo /etc/init.d/apache2 restart

E temos neste momento o servidor Apache configurado para usar o repositório SVN ProjX! Basta abrir um browser e apontar para o URL http://localhost/ProjX. Mas, neste exemplo, não estamos a usufruir da autenticação. Para tal, alteramos de novo o ficheiro apache2.conf e adicionamos:

<Location /ProjX>
  DAV svn
  SVNPath /home/projecto/ProjX
  AuthType Basic
  AuthName "Repositorio para o ProjX"
  AuthUserFile /etc/svn-auth-file
</Location>

Criamos o ficheiro /etc/svn-auth-file e adicionamos credenciais para os utilizadores que pretendemos que tenham acesso ao servidor SVN:

$ htpasswd -cm /etc/svn-auth-file utilizador1
New password: *****
Re-type new password: *****
Adding password for user utilizador1
$ htpasswd -m /etc/svn-auth-file utilizador2
New password: *******
Re-type new password: *******
Adding password for user utilizador2
$
A opção -c é usada para criar o ficheiro se ainda não existir, e a opção -m é para usar encriptação MD5 nas passwords, que é mais seguro.

Podemos ainda usufruir da autorização baseada em caminhos, em que dizemos ao servidor HTTP que determinado utilizador só tem acesso a determinada pasta. Para tal adicionamos ao ficheiro apache2.conf:

LoadModule authz_svn_module   modules/mod_authz_svn.so

(na secção de carregamento dos módulos)

<Location /ProjX>
  DAV svn
  SVNPath /home/projecto/ProjX
 
  Require valid-user
 
  AuthType Basic
  AuthName "Repositorio para o ProjX"
  AuthUserFile /etc/svn-auth-file
  AuthzSVNAccessFile /etc/access-file
</Location>

E criamos o ficheiro /etc/access-file indicando que acesso por pasta cada utilizador tem:

[ProjX:/trunk/pasta1]
utilizador1 = rw
utilizador2 = r

Neste exemplo, indica-se que o utilizador1 tem permissões de escrita e de leitura à pasta1 mas o utilizador2 só pode ler os conteúdos desta pasta.

Existem bastante mais goodies e formas de configurar a autenticação e autorização do servidor Apache. Ver a documentação online aqui.

Clientes Gráficos/IDEs

SVN no Eclipse (plugin Subclipse)

Nesta secção vamos ver como instalar o plugin Subclipse para o editor Eclipse. Existem outros plugins, nomeadamente o Subversive, mas nesta secção iremos apenas detalhar a instalação do Subclipse.

Para adicionar suporte ao SVN no editor Eclipse (versão Ganymede), basta seguir os passos:

  1. Aceder ao menu Help → Software Updates…
  2. Aceder à tab Available Software e pressionar o botão Add site…
  3. No URL escrever
    http://subclipse.tigris.org/update_1.4.x

    e carregar no botão OK

Uma nova entrada com o nome do URL vai surgir na lista de software disponível. Expandir a entrada e seleccionar o Subclipse e o adaptador JavaHL como se indica a seguir:

Pressionar o botão Install… para que o Eclipse calcule as dependências deste plugin e outros pacotes que sejam necessários descarregar. Na janela que surgir pressionamos o botão Next >, aceitamos os termos da licença e pressionamos no botão Finish para dar início à instalação. Por fim, surgirá uma janela para reiniciarmos o Eclipse. Escolher Yes e temos neste momento o plugin Eclipse correctamente instalado no ambiente de desenvolvimento Eclipse.

Podemos ver que temos o plugin Subclipse ao aceder ao menu File → New → Other… e vemos a entrada SVN para fazermos checkout de um projecto SVN, como se indica na figura seguinte:

SVN no trabalho colaborativo (Trac)

O Trac é um sistema de gestão de projectos e de bug-tracking que integra numa wiki o conteúdo de repositórios SVN para uma rápida visualização do que se passa nos mesmos. Para além de possibilitar aceder a todo o código de um repositório SVN (com highlight de código), permite introduzir na wiki os objectivos e os prazos para o projecto, os bugs encontrados, e aferir o que cada utilizador tem alterado no projecto, entre outras funcionalidades muito interessantes para uma visualização intuitiva e rápida dos projectos. Vale a pena instalar este sistema, que para além de ser open source, ajuda no controlo e na análise das alterações de um projecto: possibilita ver que modificações foram feitas a dada revisão, ver diferenças entre diferentes projectos que estão num mesmo repositório, descarregar o conteúdo do projecto num arquivo .zip, para além de que é uma wiki com tudo o que de bom existe no trabalho colaborativo numa wiki!

Previamente a instalar o Trac e associar a um projecto SVN é necessário ter instalado previamente o seguinte conjunto de software:

  • Python, com uma versão superior ou igual à 2.3
  • Genshi, com uma versão superior ou igual à 0.5
  • Uma base de dados (SQLite, PostgreSQL ou MySQL) e os correspondentes drivers Python para a mesma.

Em Linux (distribuição Ubuntu) basta fazer numa linha de comandos

$ sudo apt-get install trac

para ter o trac instalado.

Para mais informações sobre os requisitos de instalação do Trac, ver a página oficial de instalação do Trac aqui.

Em alternativa, em Windows, é preciso descarregar o arquivo .zip ou o instalador .exe do Trac. Se se optar por descarregar o instalador .exe, é apenas necessário executá-lo e seguir as indicações que surgem no ecrã. Por outro lado, se se optar por descarregar o arquivo é necessário extraílo e seguir o passo (debaixo da pasta extraída):

python ./setup.py install

Este passo instala a ferramenta de administração trac-admin, usada para se criar e manter ambientes de projectos, bem como o servidor tracd.

Para se criar um ambiente para um projecto SVN previamente criado, em Windows ou em Linux, usa-se o comando trac-admin, como no se indica no exemplo seguinte para Linux (em Windows é semelhante mudando apenas o caminho para a pasta que vai ter o ambiente Trac):

$ trac-admin /home/projectos-trac/ProjX initenv
A pasta /home/projectos-trac/ProjX deverá estar previamente criada e vazia.

Durante este script será pedido para indicar a pasta onde se encontra o repositório SVN, o nome para o Projecto Trac, e mais informações (que podem ser deixadas com o valor por omissão, dando Enter para continuar a instalação do ambiente). Quando o script terminar, resta iniciar o servidor tracd e pondo-o a apontar para o projecto Trac já criado em /home/projectos-trac/ProjX:

$ tracd --port 8080 /home/projectos-trac/ProjX -d &

Desta forma, o servidor está à escuta na porta 8080. Quando abrirmos um browser e apontamos para o URL http://localhost:8000/, obtemos a página inicial da nossa wiki recém-criada, com o código do projecto SVN disponível após se pressionar o botão Browse Source:

Resta apenas começar a editar as páginas da wiki e a usar os plugins disponíveis para usufruir de uma maior facilidade de trabalho colaborativo.

Conclusões

O controlo de versões de software é imprescindível no desenvolvimento de software. Não só permite agilizar o mesmo como também fornece segurança aos programadores para avançar com as suas implementações sem risco de se perder código. O controlo de todo o software, desde a ideia inicial até às sucessivas iterações por que passa uma ideia, é registado pelo VCS. Se houver necessidade de voltar atrás, é rápido, simples e é garantido que se tem a versão anterior pretendida sem perda de código.

O Subversion na sua globalidade é um excelente VCS, que tem visto um aumento de popularidade entre programadores de todo o mundo. Para além de fornecer características importantes para a produtividade do software, tais como a atomicidade dos commits, a gestão das fusões de código de diferentes programadores, o versionamento de directorias e o custo das operações ser proporcional ao tamanho das alterações (e não ao tamanho dos ficheiros), é ainda software livre que pode ser usado com outras ferramentas (Apache, Trac) para se ter uma solução valiosa face a sistemas comerciais (sobre este aspecto, ver Testemunhos).

Para além disto, o Subversion é desenvolvido por milhares de programadores em todo o mundo, que trabalham para o aumento da qualidade deste VCS, e é suportado por uma extensa comunidade online. Uma forma rápida de ficar a saber trabalhar com o Subversion é através dos exemplos do livro online SVN Red Book e das questões levantadas nas mailing lists do Subversion.

Como limitações, o Subversion tem apenas controlo de acessos dos utilizadores por directoria e não tem ainda uma maior "granularidade", no que toca ao acesso dos ficheiros. Um exemplo disto é quando existe um projecto com pastas lib, include, bin, que deviam de ter segurança implícita (ou seja, o nome das pastas já diz implicitamente o que certos actores podem fazer, como os programadores só acederem à pasta lib e include, e os testers do projecto acederem exclusivamente à pasta bin, onde se encontram os binários a serem alvo de testes).

Outro problema actual com o Subversion é a administração de um repositório, em que não é de todo fácil apagar revisões que são lixo. Por exemplo, se uma revisão não interessar ou representar um retrocesso para outra que já existia, não é fácil apagar essa revisão do repositório. Isto é um pouco deselegante, uma vez que o repositório fica com revisões que não tem interesse de manter. Por fim, outro dos problemas prende-se com as pastas ocultas .svn, pois se o programador acidentalmente apagar esta pasta oculta, perde a forma de indicar ao servidor de SVN que fez modificações nessa pasta. Existe um procedimento para reverter esta situação, mas não é simples o suficiente e poderia estar já integrado à partida no Subversion.

Independentemente destas desvantagens, o Subversion é um VCS que representa uma mais-valia, não só para o ambiente empresarial, mas também para o dia-a-dia de um programador ou ainda aluno de uma faculdade (e por que não cada aluno ter uma conta SVN e fazer commits dos trabalhos para um repositório central SVN da faculdade?). De notar que o Subversion pode ser usado para qualquer projecto e não tem necessariamente de ser um projecto de software; o importante é a garantia que o Subversion fornece em guardar as alterações que se façam num projecto e o conjunto rápido de informação que se reúne sobre essas mesmas alterações. A partir daí, o projecto em si pode ser de qualquer área de negócio (ver esta lista de projectos que adoptaram o Subversion).

Com este artigo espera-se que o utilizador tenha ficado a conhecer mais sobre a importância do controlo de versões do software e da segurança que advém deste controlo, para além de ficar a saber como instalar e usar o Subversion, bem como das ferramentas que são mais usadas actualmente com este software de controlo de versões.

Recursos e Referências Electrónicas

revistaprogramar_arquivo/18_edicao/capa2.txt · Última modificação em: 2018/05/14 21:37 (edição externa)