Este é um pequeno artigo que tem a intenção de resumir , para iniciantes no assunto, como eu, as principais funcionalidades e conceitos por trás do controle de versão (versionamento) feito através do Subversion ou SVN.

Atenção! Este artigo foi todo baseado no UBUNTU, mas pode ser facilmente modificado para se aplicar em qualquer S.O, como o windows.


Como o título pode sugerir, não pretendo aqui abordar as inúmeras funcionalidades ou mesmo mostrar todo o poder do subversion. Sou um programador PHP que, a maioria do tempo, trabalho sozinho nos meus projetos, apenas sendo ajudado no que tange ao projeto gráfico dos sites pelos meus amigos.

A idéia é mostrar como usar, de forma prática, o controle de versão, por pessoas como eu, que não obrigatoriamente estão trabalhando em grandes equipes. Deixando claro que, os conceitos aqui apresentados, poderão ser extendidos.

Começemos pelo começo !

Para que serve este negócio de controle de versão ?! A finalidade é dar um controle maior sobre tudo que você altera no seu projeto!

Pausa para explicação!

Projeto: Nome que inventamos de dar a um monte de arquivo e diretório junto! Ou seja, para o Subversion é tudo arquivo e diretório! Problema seu se você quis chamar isso de projeto!

Digamos que ele permite você ter um histórico de tudo que você fizer. Se você modificou aquela rotina para otimizar uma
montagem_pensamento_inicial.jpg consulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que era exibida em determinada página html, tudo fica lá guardado! Pra que isso ? Para o caso de sua alteração causar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudo correto, basta um simples comando e você recupera o estado anterior.

O Melhor de tudo, na minha opinião, é que você fica livre para mexer como quiser no seu projeto sem precisar ficar fazendo backups !

Vai me dizer que você nunca pegou um arquivo fonte para alterar aquela função vital e só por via das dúvidas fez um backup e deixou lá : arquivoFonte.bkp. Ai depois precisou fazer outra alteração, e lá foi você fazer um outro backup : arquivoFonte-20070507.bkp ?! Ou ainda resolveu fazer uma alteração substancial em várias partes do site e ai resolveu, por via das dúvidas, copiar todo o diretório e criar um outro: projetoBackup ! Nunca fez isso ? Sorte sua amigo, pois muita gente faz isso e fica com aquele monnnte de arquivos no diretório.

Vamos só explicar, antes de mais nada, alguns conceitos.

<conceitos>

Repositório!

Segundo o Houaiss, lugar onde se guarda, arquiva, coleciona alguma coisa. Traduzindo. Nada mais é do que o local onde você vai guardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu pendrive, ou em um server na china.

Repositório = Diretório = Pasta

A única diferença entre um repositório e um diretório qualquer do seu disco, é que o repositório é uma pasta que é controlada pelo Subversion, ou seja, ele vai colocar um bocado de coisa lá dentro e vai controlar tudo. Logo, não se preocupe se você não entender o que tem lá dentro. Simplesmente saiba que ele vai controlar tudo direitinho.

Cópia de Trabalho (Working Copy)

Novamente, nada mais é que um Diretório, pasta, qualquer.

Comece a perceber que,para o subversion, tudo se resume a diretórios (pastas) e arquivos. Este negócio de repositório, Cópia de Trabalho, Projeto, é tudo criação da sua cabeça.

A única diferença deste diretório para o Repositório, é que é neste que você trabalha, ou seja, faz as modificações, cria, apaga as coisas. O outro (repositório), é o seu Backup, para onde você manda, por segurança, tudo que você alterou, criou, apagou.

Se tudo é Diretório, qual a diferença entre um diretório qualquer do meu HD, para o Repositório e para a Cópia de Trabalho ? A única diferença é que o Subversion tem controle sobre estas duas últimas, não fazendo a mínima idéia do que fazer sobre todas as outras!

</conceitos>

Resumão!

Tudo se resume a pegar os arquivos do repositório (como quem tira os cadernos da gaveta), fazer as alterações necessárias, enviar de volta para o repositório (guardar os cadernos novamente). E assim sucessivamente.

Vamos Detalhar um pouquinho melhor!

Lembre-se: Você vai trabalhar em um diretório, que chamamos de Cópia de Trabalho (Working Copy) !

O funcionamento básico do controle de versão, resumidamente, consiste em:

 

Criou o Supusitório? Opa, é repositório rapá!
(SVNADMIN CREATE)

Caso ainda não exista uma pasta no seu computador, no seu pendrive, em um servidor qualquer da china, é hora de criar o repositório. Claro, você só vai criar se você tiver este poder né mesmo! A Idéia deste artigo é mostrar como isso é feito localmente, na sua máquina mesmo. Caso necessite, existem servidores pagos e gratuitos , como o projeto OpenSVN (https://opensvn.csie.org/) que permite que você tenha um repositório  longe do seu computador.

Para criar um repositório, você vai utilizar o comando svn create. Como a idéia aqui é mostrar como utlizar o subversion, do ponto de vista , de um programador que trabalha sozinho, este passo será necessário. A não ser que se escolha utilizar um servidor externo.

O processo é simples. Basta digitar :

$svnadmin  create  <CaminhoDoDiretorio>

Este comando irá criar o Diretório que será considerado o repositório do seu projeto.

Eu tou começando a usar o meu pendrive como repositório. Isso mesmo. Crio o meu repositório no meu pendrive, e ele vai comigo para onde eu quiser. Quando eu chego em outro micro, plugo o pendrive, faço um checkout (explicado mais abaixo), trabalho do jeito que eu quero, e no final, basta desplugar o mesmo, clocar no bolso e ir pra casa. Qual a vantagem disso em relação a um servidor externo ? Boa pergunta! Velocidade, e acesso aos meus projetos, mesmo em micros sem acesso a internet. Qual a desvantagem ? A inicial é que só eu posso usar isso, ou seja, se quiser um repositório compartilhado com mais pessoas, não dá.

Exemplo Prático:

$mkdir /home/diego/repositorio
$svnadmin create  /home/diego/repositorio/sitePessoal

Vai começá ? Coloque as coisa sob o chicote do seu Subversion!
(SVN IMPORT)

Uma vez que o repositório esteja criado, ou tenha sido escolhido, deve-se pegar os arquivos do seu projeto, que deverão estar em uma pasta qualquer, e colocar no mesmo, para que o subversion possa começar a controlar as alterações que você fizer! Imagine isso como um Backup inicial de tudo que você já tem ou não tem.

Pausa para alguns conceitos!

O pessoal que trabalha com Controle de Versão, adora definir algumas coisas como “boa prática” ou mesmo como “regras”, mas nada disso que vou falar abaixo, é obrigatório de ser utilizado.

Como já vimos anteriormente a única coisa que o subversion entende são arquivos e diretórios, logo pouco importa o nome que damos a eles, ok ?

O “Povo”, que utiliza o subversion, defende duas correntes. Uma diz que você deve criar um repositório (Diretório) para cada projeto. Assim:

RepositorioAplicacao1

RepositorioAplicacao2

E outra que você deve ter um único repositório (diretório), guardando vários projetos. Assim:

Repositorio

    +——- Aplicacao1

     ‘——– Aplicacao2

E ai, qual usar ? Bem, pra mim, tanto faz. O Subversion só entende diretórios mesmo. Claro, isso no entendimento básico. Como não sou nenhum expert, me parece que tem sim diferença quando você começa a usar permissionamento de quem pode mexer em que.

Outra é que, independente de como você escolheu acima, deve, ao criar o seu repositório ,estruturá-lo através de 3 diretórios, assim:

RepositorioAplicacao

     +——— trunk

     +——— branchs

      ‘———- tags

Pra que isso ? E eu sei lá! Brincadeira! Explico.

Bem, isso é muito utilizado quando você tem uma aplicação de médio/grande porte onde você tem vários desenvolvedores ou mesmo naquelas que você tem previsão de muitos versões. A idéia aqui é dividir para facilitar.

No diretório trunk deve-se colocar o projeto inicial. Seria o que o pessoal chama de linha de desenvolvimento padrão. Você começa por ai e desenvolve tudo ai dentro.

Se por um acaso você (ou outro desenvolvedor) decide, de repente, adicionar uma funcionalidade revolucionária que não estava prevista no projeto como por exemplo, a implementação de uma comunicação audio/visual em tempo real para habitantes de outros planetas, a idéia é que você faça isso em uma branch! Ou seja, você copia o estado atual da sua aplicação, ou seja, copia os arquivos todos, que estão no diretório trunk para um subdiretório dentro de branch, por exemplo, vers_comunicador_marte. Por que isso ? Porque imagine que você decida fazer isso na linha principal de desenvolvimento, ou seja, no diretório trunk. O que pode acontcer ? Pode acontecer de, por isto tudo ser um teste, quebrar a aplicação. Se você separa em um outro diretório, neste caso, um subdiretório dentro de Branch, você pode testar a vontade, sem pertubar os outros, concorda ?! Então é isso! :D

Quer ver outra explicação porquê você deve fazer uma cópia dentro do branch ? Imagine que você esteja desenvolvendo a sua aplicação, digamos versão 1.0, e ai decide que vai começar a versão 2.0, que terá umas funcionalidades malucas, mas não quer deixar de dar suporte na versão 1.0, que é a que todo mundo usa. O que você faz ? Você continua com o desenvolvimento normal, da versão 1.0, dentro do trunk, e cópia tudo para um subdiretório, por exemplo, versao2, dentro do branch, e começa a trabalhar nesta nova versão lá. Sacou ?

Beleza! E o diretório tags ?! Bem, este diretório é utilizado para criar um snapshot, um instantâneo da sua aplicação. Como assim ? Quando o pessoal vai desenvolvendo uma aplicação e vem corrigindo bugs, adicionando funcionalidades extras, etc, geralmente o que fazem é dar nomes ou números a estas versões , correto ?  Por exemplo: aplicacao_ver_1.0, aplicacao_ver_1.1, etc.

A questão é, como será que você faria para distribuir esta aplicação ? Bem, você faria uma cópia da sua aplicação naquele exato momento que você definiu como uma nova versão, empacotaria e pronto! Estaria feito a versão 1.XX.YY, ok ? E se daqui a duas semanas, resolvesse que deveria lancar uma outra versão que corrigisse uns bugs, faria a mesma coisa, correto ? Bem, a idéia aqui é a mesma. Só que você vai deixar o subversion controlar isso pra você.

O que o pessoal faz, e você vai fazer, se quiser claro, é, quando decidir que uma aplicação deve ter uma nova versão lançada, você vai e copia tudo, todos os seus arquivos, diretórios, etc, para um subdiretório dentro de Tags, como por exemplo, versao1.1. E se daqui a duas semanas decide que vai lançar outra versão, cópia tudo de novo para um outro diretório, dentro de Tags, chamado versao1.2, ok ?

A questão é que, quando você acessar o diretório trunk, você terá o desenvovimento principal da sua aplicação, ou seja, o que você vem mexendo no dia a dia.

Quando você acessar um subdiretório dentro de branch, você estará acessando uma versão que você ainda está desenvolvendo e testando. É uma outra linha de desenvolvimento.

E dentro de tags, você terá instantâneos da sua aplicação em momentos que você definiu, sacou ?

E ai você pode perguntar. Beleza, tudo bem, fica tudo muito organizado, mas já imaginou a quantidade de arquivos que eu vou ter na minha máquina ? Um bocado, repetido em tudo que é canto !  Ai que está. O Subversion controla tudo isso de maneira magistral, só copiando o que deve ser copiado e fazendo links simbólicos internos ,etc, etc, etc. Ou seja, você terá o mínimo de arquivos duplicados.

Resumo da história. Tudo isso é apenas convensão para sua organização. Se você não quiser. Não precisa criar diretório trunk ou  branch ou  tag ou qualquer outro. Como falei antes, o Subversion entende apenas diretórios e arquivos, ou seja, para ele, trunk, branchs, tags são apenas diretórios, você ou quem utiliza que convenciona como vai utilizá-los. Isso é tão verdade, que se você quiser, nem precisa criá-los ou pode até criá-los com outros nomes, por exemplo: Em vez de trunk, colocar LinhaPrincipal, em vez de Branchs, LInhasDeTestes e em vez de Tags, VersoesLancadas.

E isso se aplica a desenvolvimento de sites ? Bem, ai é com vocês! Se achar que se aplica, utilize para organizar melhor as coisas, se não, esqueça e pronto. Só Lembre-se: TUDO É DIRETÒRIO e OPERAÇÕES DE BACKUP.

E depois de tudo isso, o que eu devo fazer, pelo amor de Deus ?

Bem, se você quiser utilizar o que falei acima, ou seja, utilizar estas convenções, crie os diretórios trunk, branchs, tags, coloque toda a sua aplicação (arquivos fontes, diretórios, etc) dentro do trunk, e importe tudo para o repositório. Este ato de importar, está indicando para o subversion que ele deve copiar tudo que está na sua pasta para o seu repositório e deve começar a controlar as coisas.

Continuando o Exemplo Prático:

Continuando o exemplo anterior

$cd /home/diego/temp
$mkdir MinhaAplicacao
$mkdir MinhaAplicacao/trunk
$mkdir MinhaAplicacao/branchs
$mkdir MinhaAplicacao/tags
$cd MinhaAplicacao

Observação: Caso você já tenha algo desenvolvido do seu projeto, conforme a convenção explicada acima, coloque tudo dentro do diretório trunk.

$svn import   .   file:///home/diego/repositorio/sitePessoal/trunk/ 

Observação2: Estou utilizando, nos exemplos, um repositório local, que fica na mesma máquina. Como dito anteriormente, o mesmo pode estar em um servidor remoto, e ai o acesso pode se dar pelo protocolo http. Neste caso você utilizaria, no lugar de file://, http://<servidor>/<Repositorio>

Atente para o fato de que, mesmo estando na mesma máquina, o acesso ao repositório, feito pelo svn, é através de uma URL, neste caso file://.

E esse tar de Uorqui Copí ?!
(SVN CHECKOUT)

Como explicado anteriormente, o subversion só controla dois diretórios: O repositório e a Cópia de Trabalho. É necessário, caso você ainda não possua, criar uma cópia de trabalho. Isso nada mais é do que pegar o que tem no seu repositório, ou seja, seu backup, e colocar em uma pasta qualquer. A partir deste momento, você terá uma cópia de trabalho do seu projeto, onde deverá efetuar todas as alterações.

Atenção! Atenção! LEIA RAPÁ !

Quando você faz o IMPORT do seu projeto para o repositório, como explicado no item anterior, o diretório não fica automaticamente controlado pelo Subversion! Por isso ele pode ser descartado, apagado, jogado fora, esquecido, deletado. Entendeu ?

Logo, para começar a trabalhar no seu projeto, depois de importá-lo para o repositório, é obrigatório que você faça um checkout, ou seja, copie tuuuuudo de volta, do repositório para algum diretório (work copy).

Este processo de checkout é sempre utilizado quando se vai começar a trabalhar no projeto, caso você não possua uma cópia de trabalho (work copy), em sua máquina ou em uma máquina nova. Caso já possua, geralmente se faz um update apenas, que tratará de atualizar a sua versão da cópia de trabalho de acordo com a que está no repositório.

Também é utilizado, quando você quer pegar uma versão qualquer do seu projeto, que não a última, ou mesmo, uma versão que está em algum branch.

Continuando o exemplo prático

$mkdir /home/diego/projetos/CopiaTrabalhoSitePessoal
$cd /home/diego/projetos/CopiaTrabalhoSitePessoal
$svn checkout  file:///home/diego/repositorio/sitePessoal/trunk/

Caso você queira trabalhar em um branch específico, por exemplo, uma versão 2 que você está desenvolvendo, em vez da linha de desenvolvimento principal:

$svn checkout file:///home/diego/repositorio/sitePessoal/branchs/ver2

Não sei se vocês notaram, mas até agora, tudo se resumiu a copiar de um diretório para outro, só que ao invés de usar comandos do sistema operacional, estamos usando o subversion.



Alterô os Arquivo ?! Ouxe, Diz pro Seu Subversion cuidá dêles.
(SVN COMMIT)

Toda e qualquer alteração na sua cópia de trabalho não é automaticamente controlada pelo subversion! Não? Não! Uma vez que você tenha alterado um arquivo, você precisa dizer para o subversion que você alterou e que ele deve ser enviado para o repositório!

Opa! Perai! Mas se o repositório é um backup, ele vai apagar meu backup anterior! Naaada disso! Ai é onde está o pulo do gato. O Subversion, não apagar nunca seus arquivos, apenas ele vai criar uma nova versão do seu arquivo lá! Ou seja, vai existir a cópia anterior e a nova cópia! :D Isso é o que se chama de revisão. Toda vez que você altera algo e manda para o repositório, você está criando uma nova revisão.

Continuando o exemplo prático
$cd /home/diego/projetos/CopiaTrabalhoSitePessoal
$svn commit file:///home/diego/repositorio/sitePessoal/trunk/ 


Criô ? Apagô ? Tá bulindo nas coisa né ? Vô dizê pro Seu Subversion!
(SVN ADD, DELETE, MKDIR, etc)

Assim como as alterações nos arquivos, quando você cria um novo diretório dentro do seu projeto, apaga, mude de lugar, ou seja, mexe na estrutura do seu projeto, você precisa informar isso para o Subversion.

Tudo isso é feito através dos comandos ADD, DELETE, MKDIR, etc. Veja abaixo, no Exemplo Prático da Vida Real, como trabalhar com estes comandos.


E se eu já tô cum minha Uorqui Copi, como qui eu dexo ela atualizadinha ?
(SVN UPDATE)

Isso é feito através do comando UPDATE, que tem a finalidade de atualizar a sua cópia de trabalho.  

E como é que se mexe nestes tar de BRUNCH, TAG ?

Quer saber mesmo ? Então veja o Exemplo Prático da Vida Real abaixo. É facim facim. 




Exemplo Prático da Vida Real



1. Criando o Repositório em uma pasta qualquer

/tmp# mkdir repositorios
/tmp# cd repositorios/
/tmp/repositorios# svnadmin create HelloWord
/tmp/repositorios# ls -lh

    total 4,0K
    drwxr-xr-x 7 root root 4,0K 2007-05-29 09:31 HelloWord

/tmp/repositorios# ls -lh HelloWord/

    total 28K
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 conf
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 dav
    drwxr-sr-x 5 root root 4,0K 2007-05-29 09:31 db
    -r–r–r– 1 root root    2 2007-05-29 09:31 format
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 hooks
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 locks
    -rw-r–r– 1 root root  229 2007-05-29 09:31 README.txt

2. Criando o diretório e estrutura da nossa futura aplicação.

/tmp/repositorios# cd ..
/tmp# mkdir HelloWord
/tmp# cd HelloWord
/tmp/HelloWord# mkdir trunk
/tmp/HelloWord# mkdir branchs
/tmp/HelloWord# mkdir tags
/tmp/HelloWord# ls -lh

    total 12K
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 branchs
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 tags
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 trunk

/tmp/HelloWord# cd trunk
/tmp/HelloWord/trunk# echo “<?php echo ‘pagina inicial’; ?>”  > index.php
/tmp/HelloWord/trunk# cat index.php

    <?php echo ‘pagina inicial’; ?>

/tmp/HelloWord/trunk# ls -lh

    total 4,0K
    -rw-r–r– 1 root root 32 2007-05-29 09:41 index.php

3. Importando (enviando) a aplicação para o repositório.

/tmp/HelloWord/trunk# cd ..
/tmp/HelloWord# svn import . file:///tmp/repositorios/HelloWord/  \
                        -m “Importacao Inicial”

    Adicionando    branchs
    Adicionando    trunk
    Adicionando    trunk/index.php
    Adicionando    tags

    Commit da revisão 1.
/tmp/HelloWord# ls -lh /tmp/repositorios/HelloWord/

    total 28K
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 conf
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 dav
    drwxr-sr-x 5 root root 4,0K 2007-05-29 10:09 db
    -r–r–r– 1 root root    2 2007-05-29 10:09 format
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 hooks
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 locks
    -rw-r–r– 1 root root  229 2007-05-29 10:09 README.txt



    Observe que a estrutura de diretórios do repositório, apesar da importação(cópia), não mudou em nada, pois o subversion trata de controlar tudo isso internamente. Era de se esperar que aparecessem as pasta s trunk, branchs, tags dentro de /tmp/repositorios/HelloWord,  já que a importação nada mais é do que uma cópia não é mesmo ? ;D

    Observe também que todas as operações com o subversion, de importação, de update, de checkout, etc, devem ser realizadas na raiz do projeto, neste caso o diretório /tmp/HelloWord.


4. Apagando o conteúdo do diretório, que já não é mais necessário, e que não é controlado pelo subversion, e fazendo o primeiro checkout.

/tmp/HelloWord# rm * -r
/tmp/HelloWord# svn  checkout  file:///tmp/repositorios/HelloWord/trunk   .

    A    index.php
    Gerado cópia de trabalho para revisão 1.

/tmp/HelloWord# ls -lh

    total 4,0K
    -rw-r–r– 1 root root 32 2007-05-29 10:19 index.php



    Observe que, como pedimos para fazer o checkout do trunk, veio apenas o arquivo index.php. Lembre-se, não ficaremos fazendo checkout de toda a estrutura que importamos, mas apenas do que nos interessa, ou seja, o que estiver dentro do trunk, ou de branchs ou mesmo de tags.



5. Alterando o conteúdo do arquivo e dando commit para forçar a atualização do Repositório.

/tmp/HelloWord# echo “<?php echo ‘linha2′; ?>” >> index.php
/tmp/HelloWord# cat index.php
   
    <?php echo ‘pagina inicial’; ?>
    <?php echo ‘linha2′; ?>

/tmp/HelloWord# svn status
   
    M      index.php

/tmp/HelloWord# svn commit -m “index.php modificado”

    Enviando       index.php
    Transmitindo dados do arquivo .
    Commit da revisão 2.

    Observe que, após a edição do arquivo, ao se executar o comando svn status, o mesmo retorna indicando que o index.php foi Modificado.

    Quanto se executa o commit o arquivo Modificado é enviado para o repositório e o prrojeto fica na revisão 2.



6. Alterando a estrutura (diretórios e arquivos) do projeto.

/tmp/HelloWord# mkdir cpanel
/tmp/HelloWord# cd cpanel
/tmp/HelloWord/cpanel# echo “<?php echo ‘PainelDeControle’; ?>”  >   \
                                 cpanel.php
/tmp/HelloWord/cpanel# cd ..
/tmp/HelloWord# svn status
   
    ?      cpanel

    Observe que o subversion mostra uma interrogação ao lado do diretório que acabamos de criar. Isso indica que este diretório ainda não é controlado pelo subversion, ou seja, ainda não está no repositório. Precisamos adicioná-lo ao repositório.

/tmp/HelloWord# svn add cpanel/
    A         cpanel
    A         cpanel/cpanel.php

    Observe que ele automaticamente adiciona tudo que está dentro do diretório cpanel. Vale lembrar que, apesar do comando ter sido bem sucedido, o mesmo ainda não foi definitivamente concretizado. Para isso, precisamos chamar novamente o commit.

/tmp/HelloWord# svn commit -m “+ Diretorio cpanel”
    Adicionando    cpanel
    Adicionando    cpanel/cpanel.php
    Transmitindo dados do arquivo .
    Commit da revisão 3.

    Veja que automaticamente todo o conteúdo do diretório foi enviado ao repositório e agora o nosso projeto se encontra na revisão 3.

    vamos adicionar mais um arquivo no nosso cpanel e ver o que acontece.

/tmp/HelloWord# echo “<?php echo ‘moduloUsuario’; ?>” >  \
                        cpanel/user.php
/tmp/HelloWord# svn status

    ?      cpanel/user.php

    Como esperado, o status retorna informando que o arquivo user.php ainda não está sobre controle do subversion. Logo vamos adicioná-lo.

/tmp/HelloWord# svn add cpanel/user.php

    A         cpanel/user.php

/tmp/HelloWord# svn commit -m “+ modulo usuario”

    Adicionando    cpanel/user.php
    Transmitindo dados do arquivo .
    Commit da revisão 4.

    Agora nosso projeto se encontra na revisão 4. Acho que você já deve ter notado que a cada commit o número da revisão é incrementado.  Deve ter notado também que a cada arquivo criado, deve-se adicioná-lo ao repositório correto ? Correto! E deve estar pensando na trabalheira que é, se eu adcionar um monte de arquivos ou se eu tiver que ficar dando add e commit a cada arquivo criado. Pois é ! Mas hoje já existem aplicativos, como o rapidSVN, o TortoiseSVN(para windows), scripts que se integram ao nautilus, etc, que fazem tudo isso na interface gráfica. Ou seja, o que estamso fazendo aqui, manualmente é para que você entenda o conceito, já que o modo de usar os softwares pode variar de um para outro.

    Vamos imaginar agora que por um descuido você removeu o arquivo user.php, do diretório cpanel, quando era para ter removido outro.

/tmp/HelloWord# rm cpanel/user.php
/tmp/HelloWord# svn status

    !      cpanel/user.php

    Observe que o subversion retorna com o nome do arquivo removido com uam exclamação, como quem diz : Meu Deus, cadê o arquivo que eu estava controlando ?! Como isso foi um engano, e como você anteriormente já tinha colocado este arquivo no repositório, você pode atualizar a sua cópia de trabalho com o comando updatde.

/tmp/HelloWord# svn update

    Restaurado ‘cpanel/user.php’
    Na revisão 4.

    O arquivo foi restaurado. Começaram a perceber o poder deste negócio de controle de versão ?

    Com isso fica o que falamos acima. Quando quiser realmente adicionar um diretório, remover um arquivo, criar um novo arquivo, você deve fazer isso com os comandos do subversion. Na verdade, adicionar arquivo e diretórios nem é tão crítico, já que podemos utilizar o comando add posteriormente a criação dos mesmos, mas a remoção de arquivos e diretórios ou mesmo a movimentação deles para outros lugares, isto sim, deve ser feito com o subversion. Logo a remoção do arquivo, se você quiser realmente removê-lo, deve ser feita da seguinte maneira :

/tmp/HelloWord# svn delete cpanel/user.php

    D         cpanel/user.php

/tmp/HelloWord# ls cpanel -lh

    total 4,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php


/tmp/HelloWord# svn commit -m “- user.php”

    Apagando       cpanel/user.php
    Commit da revisão 5.

    E se, mesmo depois de ter apagado propositadamente, você descobre que aquele arquivo continha um trecho que você poderia necessitar ? Ou mesmo, que aquele arquivo era essencial e você não deveria ter apagado ? Será que tem como recuperar o arquivo ? Tem sim, claro. Basta você dizer para o subversion que quer que ele atualize a sua cópia de trabalho para a revisão anterior, no caso a 4.

/tmp/HelloWord# svn update -r4

    A    cpanel/user.php
    Atualizado para revisão 4.

/tmp/HelloWord# ls cpanel -lh

    total 8,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
    -rw-r–r– 1 root root 31 2007-05-29 12:59 user.php

    Observe que agora estamos trabalhando da revisão 4. A revisão 5 ainda existe, só que ela não possui o arquivo user.php. O interessante é notar que, a qualquer momento, podemos trabalhar nas revisões que quisermos, nos movimentando entre os nossos “backups”. Só que isso gerou um impasse, concordam ? Eu tenho um arquivo , que acabei apagando de propósito, mas que não era para ter apagado, na revisão 4, mas não tenho ele na revisão 5.  Se eu continuar a trabalhar na revisão 4, eu perco todas as outras alterações (se houverem), que eu tenha feito até o commit para a revisão 5. Se eu vou para a revisão 5, eu tenho todas as alterações, mas não tenho o arquivo user.php. E agora ? Quem poderá nos ajudar ? :D

    A questão é que o subversion dá nó em pingo d’água. E o que estamos escrevendo aqui é apenas uma pontinha de todo o seu poder. Como tudo para o subversion é diretório e arquivo, pensemos assim. Se eu não utiliza-se controle de versão e fizesse as coisas na mão, provavelmente eu teria  dois diretórios assim :

    HelloWordRevisao4

    HelloWordRevisao5

    Logo, ficaria muito fácil eu recuperar o arquivo, fazendo uma simples cópia entre diretórios, concorda ? Então o mesmo se aplica ao subversion, ele tem um comando chamado copy, onde você pode especificar a origem, o destino e a revisão. Então observe:

Voltemos para a revisão 5.

/tmp/HelloWord# svn update

    D    cpanel/user.php
    Atualizado para revisão 5.

/tmp/HelloWord# ls cpanel/ -lh

    total 4,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php

    Agora vamos copiar o arquivo user.php, que está na revisão 4, para a nossa cópia de trabalho atual.



/tmp/HelloWord# svn copy -r4   \
             file:///tmp/repositorios/HelloWord/trunk/cpanel/user.php   \
             cpanel/

    A         cpanel/user.php

/tmp/HelloWord# ls cpanel/ -lh

    total 8,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
    -rw-r–r– 1 root root 31 2007-05-29 13:13 user.php

/tmp/HelloWord# svn status

    A  +   cpanel/user.php

    Como podemos notar, o arquivo foi copiado do repositório para a pasta, e aparece com um A, indicando que foi adicionado a sua cópia de trabalho. Finalmente, vamos dar um commit para gravar tudo no repositório.

/tmp/HelloWord# svn commit -m “user.php recuperado”

    Adicionando    cpanel/user.php
    Commit da revisão 6.

    Imagine que chegamos ao final do dia e decidimos que esta versão final (revisão 6)  deveria sser chamada de HelloWord Versao 1.0. Podemos decorar que a revisão 6, é a versão 1.0, ou podemos dar este nome específico para esta revisão. de modo que quando fizermos referência a versao 1.0 o subversion nos traga automaticamente a revisão 6. Este processo consiste em “TAGGEAR” o projeto. Este é o motivo, já explicado acima, de termos criado o diretório tags.

    Este processo nada mais é do que uma cópia entre diretórios, utilizando o subversion.

    Antes de mais nada, vamos listar quais são as tags (versões já lançadas, digamos assim), que nós temos. Ou seja, vamos dar um ls (comando dir, para o DOS), no repositório.

/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/tags/

    Observe que nada foi retornado, como esperado.

    Para testar um pouco mais do comando list, vamos listar o trunk.

/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/trunk/

    cpanel/
    index.php

    Ele retornou com os nossos arquivos. Claro, porque estamos trabalhando sempre no trunk, lembram ? Ou seja, o comando list seria como um ls, láááá no repositório.

    Mas vamos lançar nossa versão 1.0 do nosso incrível projeto Hello Word.

tmp/HelloWord# svn copy file:///tmp/repositorios/HelloWord/trunk/  \
                       file:///tmp/repositorios/HelloWord/tags/versao1.0   \
                       -m “Lancando a versao 1.0″

    Commit da revisão 7.

    Antes de mais nada, o comando acima deve ser digitado em uma única linha. Pronto, nossa versão foi lançada. O que fizemos foi apenas copiar o que tinha no nosso Trunk para o diretório versao1.0 dentro de tags. Isso láááá no nosso repositório ok ? Ah, uma coisa. Isso não vai duplicar os milhares de arquivos que temos em nosso projeto, ele vai apenas criar links simbólicos, ok ? :D

    Vamos listar agora, quais as tags (versôes) que nós temos.

/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/tags/

    versao1.0/

    Pronto! Final do Dia. tudo correu bem. Lançamos uma versão e vamos para casa.

    Agora imagine que você chegou em casa, e lembrou que esqueceu de coloca uma pequena coisa no index.php, e gostaria de trabalhar no seu projeto. Claro, que estamos trabalhando com um repositório local, mas como dito anteriormente, o mesmo pode estar em um servidor em qualquer lugar do mundo, ou mesmo, pode estar no seu pendrive. Vamos fazer de conta, que o repositório está acessível para a gente da mesma forma que estava na outra máquina, lá no trabalho ok ?

    E agora, como eu faço para trabalhar no meu projeto ? Basta você voltar a fita e ir lááááá para o passo número 4, onde falamos em checkout. É isso mesmo. Como não temos uma Cópia de Trabalho, ainda, precisamos fazer um checkout, ou seja, copiar a revisão lá do repositório para um diretório qualquer.  Então você pode fazer, imaginando que vamos trabalhar no diretório /home/diego/temp :

/home/diego/temp# mkdir HelloWord
/home/diego/temp# cd HelloWord/
/home/diego/temp/HelloWord# svn checkout  \ 
                                         file:///tmp/repositorios/HelloWord/trunk .

    A    cpanel
    A    cpanel/user.php
    A    cpanel/cpanel.php
    A    index.php

    Gerado cópia de trabalho para revisão 7.

    Pronto, agora é só meter a mão na massa e continur com os commits, updates, etc etc etc.

    Ah, como estamos trabalhando sozinhos, os updates não se tornam tão importantes. Mas se estivermos trabalhando em dupla de dois, por exemplo, vale a pena sempre dar update para garantir que sua cópia de trabalho esteja sempre atualizada, caso seu amigo tenha feito alguma modificação.

    Espero que este pequeno grande artigo sirva para abrir os horizontes dos iniciantes no mundo do controle de versão.