Cosmo Verbal

Tortoise SVN na IDE do Delphi

Para os que gostam de vcs na ide, agora você pode ter um menu do Tortoise SNV na sua IDE Delphi, um plugin dos próprios desenvolvedores do Tortoise. Baixe o fonte (.pas) deste site ou ou diretamente clicando aqui, instale como qualquer componente e tenha um menu como o da figura abaixo na ide do seu Delphi, claro que você precisa ter o Tortoise instalado em sua máquina:

Controle de versões – Breve introdução

Conceito
Sistemas de controle de versões são muito utilizados por desenvolvedores de softwares ao redor do mundo, basicamente permite que um desenvolvedor ou uma equipe mantenha um ou mais arquivo em um repositório onde se possam recuperar versões anteriores do(s) mesmo(s) a qualquer tempo. Provavelmente todas as pessoas que lidam com arquivos em microcomputadores, de uma forma ou de outra, fazem, mesmo que inconscientemente, uso de controle de versões. Imaginemos, por exemplo, um advogado que esteja elaborando uma complexa defesa para um cliente, em determinado ponto se dá por satisfeito, imprime a mesma, mas dias depois novos fatos surgem e ele percebe que precisaria alterar parte considerável do documento, mas gostaria de manter o documento original para uma eventual necessidade caso os novos fatos não possam ser comprovados. O que a maioria das pessoas fazem para solucionar este problema é fazer as alterações no arquivo e salva-lo com um nome diferente, por exemplo, digamos que arquivo original tenha nome “defesa_cliente_x.doc”, fazemos as alterações neste arquivo e o salvamos com o nome “defesa_cliente_x_2.doc”. Desta forma mantemos o controle sobre as duas versões, a versão original e a versão para a possibilidade da comprovação dos novos fatos. Para desenvolvedores de softwares o controle manual das versões pode ser tornar quase impossível, pois os arquivos fontes são alterados com muita freqüência e a qualquer momento pode-se necessitar de uma versão de um determinado arquivo (entre muitos). Isto ainda é mais problemático quando os arquivos precisam ser compartilhados, imagine a confusão que não seria ter um arquivo ou vários arquivos repetidos dezenas de vezes com nomes diferentes em uma pasta.

Vantagens de um sistema VCS
A grande vantagem de um sistema de controle de versões automático é que as versões dos arquivos são armazenadas em um local apropriado para isto, fora da área de trabalho do usuário e que pode ser disponibilizado a qualquer um que se queira que tenha acesso aos arquivos, com um sistema vcs podemos ter os seguintes recursos:

• Backup e Restore. Os arquivos podem ser salvos logo após serem editados de forma transparente gerando uma nova versão. Desta forma pode-se ter acesso a qualquer versão no tempo. Se for necessário recuperar uma versão de um dos arquivos que foi salvo em 01/01/200, sem problema, se ele foi atualizado no sistema vcs nesta data, ele estará lá, mesmo que na sua área de trabalhão você esteja vendo apenas a versão atual.
• Sincronização. Permite sincronização de versões compartilhadas de arquivos, ou seja, permite que uma equipe faça atualizações nos arquivos e cada um possa ter a versão mais atualizada.
• Facilidade para “voltar atrás”. Se por um motivo qualquer surja a necessidade de se compilar uma versão anterior do sistema, é muito fácil recuperar os fontes desta versão.
• Acompanhamento das mudanças. À medida que se vai atualizando os arquivos pode-se (na verdade, deve-se) fazer anotações sobre as alterações, explicando onde e porque das mudanças (note que estas anotações não são armazenadas nos arquivos em si, mas no sistema vcs) Tornando mais compreensível a apresentação da evolução de um arquivo no tempo.
• Sandboxing, ou proteção contra si mesmo. Digamos que você tenha feito uma grande mudança e não esteja seguro do resultado, você pode gravar estas mudanças em uma área temporária e manter, através de tags, versões temporárias para testes até decidir a incorporação definitiva das mudanças ou não.

Jargão
Para trabalhar com um sistema vcs é necessário conhecer alguns termos:

Setup

• Repositório (repo): Base de dados onde são armazenados os arquivos.
• Servidor: O computador onde é armazenado o repositório.
• Cliente: O computador que se conecta ao repo.
• Área de trabalho: Diretório local do usuário onde são feitas as mudanças.
• Trunk: A pasta principal para o código no repositório.

Ações básicas

• Add: Adicionar um arquivo ao repositório pela primeira vez.
• Revision: A versão do arquivo (v1, v2, v3, etc.).
• Head: A última revisão no repositório.
• Check out: Retirada (download) de arquivos do repositório.
• Check in: Entrega (upload) de arquivos do repositório (quando alterados). Os arquivos recebem um novo número de revisão e as pessoas podem se quiser fazer um Chek out nos mesmos.
• Checkin Message: Mensagem descrevendo as alterações.
• Changelog/History: Lista de alterações feitas no arquivo desde a sua criação.
• Update/Sync: Sincronizar os arquivos na área de trabalho com a última versão do repositório.
• Revert: Reverter os arquivos na área de trabalho (descartando-os) para a última revisão no repositório.

Ações avançadas

• Branch: Criar uma cópia separada de um arquivo/pasta para um uso específico e/ou particular (Identificação de erros, testes, etc). Branch pode ser tanto um verbo (”branch the code”) quanto um substantivo (”Qual branch?”).
• Diff/Change/Delta: Procurar diferenças entre dois arquivos. Útil para visualizar mudanças entre duas revisões.
• Merge (ou patch): Aplicara as alterações feitas em um arquivo em outro, para atualizá-lo. Por exemplo, a aplicação de funcionalidades de um branch para outro.
• Conflict: Quando mudanças pendentes em um arquivo contradizem outras. (nenhuma das alterações não podem ser aplicadas).
• Resolve: Corrigir alterações contraditórias e fazer chekging da versão correta.
• Locking: “Obter o contole” de um aruquivo não permitindo que mais ninguém o altere até que um unlock seja feito. Alguns vcs se utilizam deste recursos para evitar conflitos.
• Quebrando o lock: Forçar o unlock em um arquivo permite a edição do memso. Isto pode ser necessário no caso de alguem fazer um lock de um arquivo e sair de férias ou, por algum motivo, abandonar o projeto.

SVN – Quick Start

Subversion – Início rápido

Depois de trabalhar por 3 anos em um servidor linux e instalar e reinstalar várias vezes softwares para controle de versões (cvs e subversion) precisei trabalhar em um servidor windows 2003 e, conseqüentemente, migrar o repositório svn, embora todos digam que o ‘mundo windows’ é tudo mais fácil e blá blá… Minha experiência contradiz este ‘senso comum’, pelo menos na esfera de servidores, como a prioridade máxima era a migração do repositório tentei ‘queimar etapas’ e recorrer a alguns amigos que considero ‘feras’ do windows e até mesmo a alguns fóruns e, para minha surpresa, descobri que a grande maioria do usuários windows nem sabem o que é um software vcs ou quando sabem (a maioria programadores) apenas conhecem o lado cliente, foi então que resolvi arregaçar as mangas e debruçar sobre o manual e ir fazendo anotações enquanto fazia a migração, destas anotações escrevi este ‘how to’, todo o material contido aqui é resumo e/ou adaptação de partes da própria documentação.

Considerações iniciais:
Segundo o próprio site http://subversion.tigris.org/project_packages.html “O projeto não endossa ou mantém pacotes binários. No entanto, voluntários tem criado pacotes binários para diferentes distribuições e plataformas….” Isto significa que se você quer a ultima versão estável do projeto provavelmente vai encontrar diferenças entre um pacote binário instalável e a versão oficial do projeto, pelo menos foi o que constatei enquanto escrevia este, no diretório dos binários windows havia a seguinte observação:

Windows binaries – ATTENTION!: The mod_dav_svn binaries available here are NOT compatible with Apache 2.2 — see the Windows Apache 2.2.x folder.

Significa que se você pretende ter o apache 2.2.x é melhor utilizar o pacote ‘não instalável’ ou você terá que editar o arquivo de configuração do apache e retirar a chamada ao modulo mod_dav_svn (se você não fizer isto o apache simplesmente não funcionará).

Se, dito isto, você ainda deseja um instalável tipo next-next-end baixe-o do diretório: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 note que os instaláveis são arquivos do tipo .exe e, na última coluna há a observação: Windows installer with the basic win32 binaries, quando escrevia este a ultima versão era a 1.4.3.

Este artigo está basedo no pacote oficial compatível com o apache 2.2.x. Então mãos a obra:

Baixando e instalando
1. Baixe o pacote : http://subversion.tigris.org/files/documents/15/36104/svn-win32-1.4.3.zip,
2. Descompacte o arquivo para um diretório em seu HD, por exemplo: c:\svn
3. Registre o serviço no windows com o seguinte comando:

sc create subversion binpath= “d:\subversion\bin\svnserve.exe –service –root d:\subversion\svnrepository” displayname= “Subversion” depend= Tcpip

Se tudo estiver ocorrido bem, deverá aparecer a mensagem:

[SC] CreateService ÊXITO

Se você recebeu uma mensagem apresentando a sintaxe do comando SC significa que você digitou algo errado ai você olha, olha e olha e nada encontra de errado, resolve redigitar cuidadosamente tudo e mais uma vez a sintaxe do comando é apresentada, não se desespere, como o windows sempre teve um shell de comando muito ‘liberal’, apesar de fraquíssimo, os usuários acostumaram a digitar descuidadamente os comandos, veja que neste caso o comando EXIGE que se respeite os espaços em volta dos sinais de =, isto é, você não pode digitar:

sc create subversion binpath = “d:\
ou
sc create subversion binpath =”d:\,

tem que ser exatamente:

sc create subversion binpath= “d:\

Ou seja, não pode haver espaços em volta do sinal de = (igualdade), Ok, estou me repetindo, mas é por um boa causa.

Criando o primeiro repositório:
1. Coloque o diretório bin da instalação no path (pelo menos enquanto trabalha na configuração do svn), se você instalou no diretório c:\svn, digite o comando:

%path%=c:\svn\bin;

2. Agora vamos criar o repositório, com o comando:

svnadmin create d:\snvrepos

Para checar execute o comando:

tree d:\svnrepos

Deverá ter como saida:

Configurando a autenticação de usuários:
Quando um cliente conecta a um servidor svn este consulta o arquivo conf/svnserve.conf para fazer (ou não) a autenticação. Dependendo da configuração neste arquivo pode acontecer:

1. O cliente pode ser autorizado a fazer requisições anonimamente, sem autenticação.
2. O cliente pode ser obrigado a fazer autenticação sempre ou
3. se operando em “tunnel mode“, o cliente se declarara como já autenticado externamente.

Criando o arquivo de usuários e o domínio:
Todos os arquivos de configuração no svn tem o mesmo formato: As seções são assinaladas por colchetes ([seção]), comentários iniciam com o sinal sharp (#), e cada seção contem variáveis específicas as quais são atribuídas valores (variável = valor). Vamos a um exemplo:

Por enquanto a seção [general] do arquivo: svnserv.conf tem todas as variáveis que você precisa. Inicia definindo o arquivo que contem os nomes dos usuários e suas respectivas senhas, e o domínio para autenticação.

[general]
password-db = userfile
realm = SVN, dominio by me

O Dominio é qualquer nome que você queira, é apenas uma ‘mensagem’ que pode indicar o tipo de autenticação ao cliente ou outra informação qualquer. A variável password-db aponta para o arquivo que contem a lista de nomes dos usuários e suas senhas, este arquivo usa o mesmo familiar formato. Por exemplo:

[users]
harry = foopassword
sally = barpassword

O valor da variável password-db (o arquivo de nomes e senhas) pode ser um path absoluto ou relativo. Para a maioria dos casos é mais fácil deixá-lo no diretório conf/ dentro do repositório, junto com o arquivo svnserve.conf. Por outro lado é possível que você queira ter dois ou mais repositórios com o mesmo arquivo de usuários, neste caso, seria melhor ter o arquivo em um diretório publico. Os repositórios compartilhariam o arquivo de usuários que poderiam também ser configurado com o mesmo domínio. De qualquer forma, o importante é definir corretamente as permissões apropriadas para cada usuário.

Configurando os controles de acessos:
há mais duas variáveis para ser configuradas no arquivo svnserv.conf: elas determinam os direitos dos usuários não autenticados (anônimos) e autenticados. às variáveis anon-access e auth-access podem ser atribuídos os valores: none, read, ou write. Atribuindo o valor none/read permite o acesso ao repositório para somente leitura (none para não autenticados e read para autenticados) e red/write permite acesso completo.

por exemplo:

[general]
password-db = userfile
realm = SVN domain by me

# usuários anônimos podem ter acesso somente leitura
anon-access = read

# usuários autenticados podem ter acesso completo
auth-acess = write

O exemplo apresenta as variáveis de forma default, você pode, se desejar, bloquear totalmente o acesso anônimo atribuindo none a variável anon-access.

[general]
password-db = userfile
realm = SVN domain by me

# usuários anônimos não são permitidos
anon-access = none

# usuários autenticados podem ter acesso completo
auth-acess = write

Note que o servidor svn fornece somente acesso completo ao repositório, o usuário pode ter acesso somente leitura, leitura/escrita ou nenhum acesso, não há a funcionalidade de acesso a partes específicas do repositório, para a maioria dos projetos isto é adequado, contudo se você precisa disponibilizar acessos por diretório então você precisa fazê-lo através do modulo mod_authz_svn do apache ou através de scripts presentes na distribuição do svn.

Criando o primeiro projeto:
Na realidade Subversion não tem o conceito de projeto. O repositório funciona como um sistema virtual de arquivos versionados, uma grande estrutura de diretório onde se pode armazenar qualquer coisa que se deseje. Alguns administradores preferem armazenar apenas um projeto em cada repositório outros preferem armazenar todos os projetos em somente um repositório, o manual descreve as vantagens e/ou desvantagens de cada abordagem, de qualquer forma o repositório só administra arquivos e diretórios, assim cabe aos humanos interpretar diretórios particulares como “projetos”. O manual deixa claro que quando se refere a projetos está falando sobre algum diretório (ou coleção de diretórios) no repositório.

Vamos trabalhar em um exemplo onde assumiremos que temos um projeto com alguns arquivos fontes em ‘c’ os quais iremos importar para dentro do repositório recentemente criado (novos usuários de controle de versões costumam ficar confusos com o termo “importar”, mas é isto mesmo, quando você grava o projeto pela primeira vez no repositório, você o importa. Vamos começar organizando estes arquivos e um diretório chamado Projeto1. Para que possamos fazer ‘Branchin and Merging’ (assunto que este artigo não cobre, mas quem sabe um outro no futuro?) a estrutura do projeto deverá ter na raiz 3 diretórios: branches, tags, e trunk. O diretório trunk deverá conter os arquivos de nosso projeto enquanto branches e tags deverão ficar vazios.

\tmp\projeto1\branches\
\tmp\projeto1\tags\
\tmp\projeto1\trunk\

foo.c
bar.c
Makefile

…

Os diretórios branches, tags, e trunk na realidade não são requeridos eles são simplesmente uma convenção que provavelmente você utilizara mais tarde.

Tendo o projeto organizado na estrutura mencionada vamos importá-lo para dentro de nosso repositório como o comando svn import:

<span style="font-size:100%;"><span id="SPELLING_ERROR_244" class="blsp-spelling-error">svn</span> <span id="SPELLING_ERROR_245" class="blsp-spelling-error">import</span> \<span id="SPELLING_ERROR_246" class="blsp-spelling-error">tmp</span>\<span id="SPELLING_ERROR_247" class="blsp-spelling-error">projeto</span>1 file:///d/svnrepos/projeto1 -m "<span id="SPELLING_ERROR_248" class="blsp-spelling-error">import</span> inicial"
</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_249" class="blsp-spelling-error">Adding</span><span> </span>\<span id="SPELLING_ERROR_250" class="blsp-spelling-error">tmp</span>\</span><span style="font-size:100%;" lang="EN-US"><span id="SPELLING_ERROR_251" class="blsp-spelling-error">projeto</span>1\</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_252" class="blsp-spelling-error">branches</span><span id="SPELLING_ERROR_253" class="blsp-spelling-error">Adding</span><span> </span>\<span id="SPELLING_ERROR_254" class="blsp-spelling-error">tmp</span>\</span><span style="font-size:100%;" lang="EN-US"><span id="SPELLING_ERROR_255" class="blsp-spelling-error">projeto</span>1\</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_256" class="blsp-spelling-error">tags
</span><span id="SPELLING_ERROR_257" class="blsp-spelling-error">Adding</span><span> </span>\<span id="SPELLING_ERROR_258" class="blsp-spelling-error">tmp</span>\</span><span style="font-size:100%;" lang="EN-US"><span id="SPELLING_ERROR_259" class="blsp-spelling-error">projeto</span>1\</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_260" class="blsp-spelling-error">trunk</span><span id="SPELLING_ERROR_261" class="blsp-spelling-error">Adding</span><span> </span>\<span id="SPELLING_ERROR_262" class="blsp-spelling-error">tmp</span>\</span><span style="font-size:100%;" lang="EN-US"><span id="SPELLING_ERROR_263" class="blsp-spelling-error">projeto</span>1\</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_264" class="blsp-spelling-error">trunk</span>\<span id="SPELLING_ERROR_265" class="blsp-spelling-error">foo</span>.c<span id="SPELLING_ERROR_266" class="blsp-spelling-error">
Adding </span>\<span id="SPELLING_ERROR_267" class="blsp-spelling-error">tmp</span>\</span><span style="font-size:100%;" lang="EN-US"><span id="SPELLING_ERROR_268" class="blsp-spelling-error">projeto</span>1\</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_269" class="blsp-spelling-error">trunk</span>\bar.c
<span id="SPELLING_ERROR_270" class="blsp-spelling-error">Adding</span><span> </span>\<span id="SPELLING_ERROR_271" class="blsp-spelling-error">tmp</span>\</span><span style="font-size:100%;" lang="EN-US"><span id="SPELLING_ERROR_272" class="blsp-spelling-error">projeto</span>1\</span><span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_273" class="blsp-spelling-error">trunk</span>\<span id="SPELLING_ERROR_274" class="blsp-spelling-error">Makefile</span>…</span>

Agora o repositório contém nossa árvore de dados. Você não será capaz de ver os arquivos ou os diretórios olhando diretamente no diretório (não adianta tentar o comando dir) os dados são armazenados dentro de um banco de dados. O sistema de arquivos imaginário dorepositório agora contém um diretório de nível mais alto (na raiz|) com o nome de Projeto1, que por sua vez contém nossos dados.

Veja que o diretório original \temp\projeto1 permanece intacto, sem alterações, o servidor Subversion nem tem conhecimento do mesmo (na verdade você pode excluí-lo, se desejar). Para começar a manipular os dados de forma versionada o próximo passo é criar uma ‘cópia de trabalho’ em uma área de trabalho que pode ser qualquer diretório em nosso HD, então vamos criar um diretório chamado trabalho e dentro dele um outro diretório chamado projeto1 será criado pelo svn no processo de retirada (checkout) este será nosso diretório que conterá nossa cópia de trabalho.

md trabalho
cd trabalho

Agora com o comando svn vamos ‘retirar’ (checkout) o projeto de dentro de nosso repositório:

<span style="font-size:100%;"><span id="SPELLING_ERROR_301" class="blsp-spelling-error">svn</span> <span id="SPELLING_ERROR_302" class="blsp-spelling-error">checkout</span> file:///d/svnrepos/projeto1/trunk <span id="SPELLING_ERROR_303" class="blsp-spelling-error">projeto</span>1</span>

<span style="font-size:100%;">A<span> </span><span id="SPELLING_ERROR_304" class="blsp-spelling-error">projeto</span>1</span><span style="font-size:100%;">/<span id="SPELLING_ERROR_305" class="blsp-spelling-error">foo</span>.cA<span> </span><span id="SPELLING_ERROR_306" class="blsp-spelling-error">projeto</span>1</span><span style="font-size:100%;" lang="EN">/bar.cA<span> </span></span><span style="font-size:100%;"><span id="SPELLING_ERROR_307" class="blsp-spelling-error">projeto</span>1</span><span style="font-size:100%;" lang="EN">/<span id="SPELLING_ERROR_308" class="blsp-spelling-error">Makefile</span></span>

<span style="font-size:100%;" lang="EN">…</span>

<span style="font-size:100%;" lang="EN"><span id="SPELLING_ERROR_309" class="blsp-spelling-error">Checked</span> <span id="SPELLING_ERROR_310" class="blsp-spelling-error">out</span> <span id="SPELLING_ERROR_311" class="blsp-spelling-error">revision</span> 1.</span>

Agora temos uma cópia pessoal para trabalho de parte de nosso repositório em nosso novo diretório chamado projeto1 dentro da pasta trabalho, agora podemos alterar os arquivos na área de trabalho e então ‘entrega-los’ (commit) ao repositório.

Note que o comando chekout utiliza a sintaxe de URL e não o caminho para a localização do projeto, atente para o fato que retiramos apenas o conteúdo do diretório trunk que foi colocado dentro da pasta projeto1, os diretórios branches e tags são ignorados neste contexto, nossa cópia de trabalho não precisa conte-los.

Altere um dos arquivos e estando no diretório de trabalho execute o comando:

svn commit

Desta forma você cria a sua primeira revisão, experimente excluir sua pasta trabalho, cria-la novamente e fazer uma nova retirada (checkout) e você verá que terá a alteração que fez antes do primeiro commit.

svn checkout file:///d:/svnrepos/projeto1/trunk projeto1

Retirando (checkout) uma revisão anterior:
Para fazer checkout da primeira versão (antes de voce fazer a primeira alteracao e executar o comit) dê o comando:

<span style="font-size:100%;">svn checkout -r1 file:///d:/svnrepos/projeto1/trunk projeto1</span>

Este é meu primeiro artigo sobre esta fantástica ferramenta, mas não será o único, outros virão, provavelmente sobre o lado cliente, e a utilização da ferramenta gui tortoisesvn.

Links relacionados:

http://www.cosmoverbal.net/subversion/controle-de-versoes-breve-introducao

http://www.cosmoverbal.net/delphi/tortoise-svn-na-ide-do-delphi