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:\

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:

dir d:\svnrepos

Deverá ter como saída:


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:

svn import \tmp\projeto1 file:///d/svnrepos/projeto1 -m "import inicial"

Adding \tmp\projeto1\branches
Adding \tmp\
projeto1\tags
Adding \tmp\
projeto1\trunk
Adding \tmp\
projeto1\trunk\foo.c
Adding \tmp\
projeto1\trunk\bar.c
Adding \tmp\
projeto1\trunk\Makefile
Committed revision 1.

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 do
repositó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:

svn checkout file:///d/svnrepos/projeto1/trunk projeto1
A projeto1/foo.c
A projeto1
/bar.c
A
projeto1/Makefile
Checked out revision 1.

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:

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

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.

Posted by Cosmo Verbal 12:55  

0 Comments:

Post a Comment