Como Remover um Commit Errado no SVN? Ou: Como Desfazer um Commit no Subversion?

Este artigo é dedicado a todos aqueles que já enviaram um commit equivocado para o SVN e quebraram ou estragaram alguma coisa no sistema onde trabalham. Quem nunca fez isso antes, que atire a primeira pedra!!
Bom, mas vamos lá.... A reposta para a pergunta acima é bem simples: não há como. Meu Deus, então agora estou perdido?? Calma, não se preocupe!! Existe uma técnica que lhe permite reverter o seu repositório para um estado anterior, se for realmente preciso. Acompanhe nosso artigo.

• Por Que não há uma Forma Direta de Desfazer Commits??

Se desejar, você pode ir imediatamente para a solução do problema, lá embaixo. Entretanto, eu resolvi incluir esta seção aqui para lhe ajudar a pensar mais sobre como funciona o SVN e quais as suas premissas, aumentando seu conhecimento sobre o mesmo.
O SVN armazena seus dados em um banco de dados interno (ou em BDB - Berkeley Data Base, ou em FSFS). Evidentemente, seria possível fazer operações comuns a bancos de dados, como delete ou roll back. Contudo, o Subversion não permite qualquer tipo de remoção de entradas (inserts) de dados que foram efetivadas, sob risco de comprometer a segurança do repositório. Observe o risco a que os desenvolvedores estariam sujeitos e a falta de confiança que se geraria sobre os repositórios se isso fosse possível, considerando cenários como:

1. Um desenvolvedor ou administrador de sistemas é demitido. Num acesso de raiva e considerando-se injustiçado, ele remove grande parte dos commits dos repositórios da empresa, deixando-os em estados muito primitivos e perdendo grande parte dos códigos gerados durante anos.
2. Um desenvolvedor mal intencionado pratica sabotagem industrial: elimina ou deturpa parte do código do sistema antes do mesmo ser compilado e o envia para produção. Após a implantação do sistema danificado, o desenvolvedor remove o trecho defeituoso que criou, eliminando a única prova concreta de sua ação.
3. Imagine que ninguém será demitido e não há qualquer pessoa mal intencionada. Ao contrário: todos trabalham felizes e freneticamente. Contudo, a equipe tem o hábito de, vez por outra, remover um commit mal feito. A uma certa altura, descobre-se um erro grave no sistema que está há mais de 1 mês em produção. A correção parece simples e poderia ser feita em cerca de um dia. Contudo, a quantidade de commits removidos impede que se consiga restaurar o código exato da versão que está em produção. Resultado: o erro vai persistir lá até que a versão seguinte seja totalmente finalizada e implantada...

Por motivos como estes, a remoção direta de commits não é possível. No entanto, existe a solução paliativa, um pouco mais agressiva, porém que funciona e é razoavelmente fácil e segura. Acompanhe-a na próxima seção!!

• Removendo um Commit Indesejado

Se é realmente necessário remover um ou mais commits do SVN, e espero que tenham sido os últimos, então a única solução é fazem um dump do repositório filtrado pelo número de revisão, eliminá-lo, recriá-lo e restaurar o dump com um load, de forma a carregar no repositório recém-criado todas as revisões até a última antes das indesejadas. Todas estas ações devem ser feitas como root!! Vamos fazer isso passo a passo...

1. Fazendo o dump:
Considere que seu repositórios se chame "repo" e você está no diretório onde ele se encontra. Primeiramente, pare todos os acessos ao repositório, para congelá-lo (ou seja, pare o Apache, se você usa o WebDAV, ou impeça o login via SSH de usuários comuns, se você usa o protocolo svn+ssh://). Descubra o número da última revisão boa (desejada), a partir da qual todas serão eliminadas (suponhamos: revisão 200), para que façamos o dump de tudo até ela. Agora, considerando esta revisão, faça o dump:

svnadmin dump repo --revision 0:200 > repo.dump

É criado o arquivo repo.dump, que contém todas as revisões deste o tenro início de seu repositório até a revisão informada, de número 200.

2. Remova o repositório e crie outro idêntico:
Se você quiser, por segurança, pode mover o repositório para outro nome ao invés de apagá-lo, de forma a manter uma cópia de segurança do mesmo, caso alguma operação falhe. Você pode também fazer um backup do diretório completo do repositório ou armazená-lo em um arquivo .tar.gz, para economizar espaço, caso o repositório seja muito grande.

rm -rf repo
svnadmin create --fs-type bdb repo

Isto recria o repositório com mesmo nome, só que agora completamente vazio.

3. Agora sim, subindo tudo!!
Rode o comando, considerando o arquivo de dump gerado e o repositório novo recém-criado. Observe que, evidentemente, convém utilizar o mesmo nome do repositório antigo, para que outras configurações de seu sistema permaneçam válidas:

svnadmin load repo < repo.dump

Se tudo deu certo até aqui, você terá seu repositório recuperado até a revisão que você informou no dump, de forma que as posteriores foram ignoradas e serão perdidas.

4. Para finalizar, não esqueça deste procedimento!! Atribua as mesmas permissões de arquivos, dono e grupo originais às pastas do repositório, especialmente ao diretório "db" e seus arquivos. Se você usa o WebDAV, por exemplo, terá de tornar os arquivos pertencentes ao usuário "www-data" (ou o nome que tem seu usuário do Apache), e não "root", como é inicialmente criado. Não esqueça de verificar se os diretórios estão marcados como executáveis, se for o caso, para permitir a criação de novos arquivos de log no diretório "db".

5. Teste tudo bem detidamente, para evitar surpresas. Em tudo funcionando, finalmente, faça a faxina: elimine ou faça backup do repositório antigo e dos arquivos de dump que ainda estão no disco.

Bom, pessoal, testei realmente todos estes comandos, embora eu mesmo já tenha me visto em situações de utilizar este mecanismo para eliminar commits errados. Torço que tudo dê certo com vocês!!

Mais detalhes sobre administração de repositórios, consultem o manual do SVN (SVN Red Book), Capítulo 5. Veja também nosso artigo completo sobre Como Fazer Backup de Repositórios SVN. E, claro, COMENTEM!!!

Configurando o WebDAV com SSL no Apache

Este é o artigo final da série sobre WebDAV e Apache, portanto assumimos que todos os passos dos artigos anteriores foram realizados com sucesso. Você poderá encontrá-los seguindo os links:

1- Como Acessar o SVN via HTTP (acesso via porta 80, sem SSL);
2- Criando Certificados SSL com OpenSSL (como criar seu certificado. Caso já o tenha, pode pular este artigo);
3- Configurando o Apache com SSL (como fazer seu Apache usar um certificado digital).

Seguindo estes passos, você deverá ter, em seu arquivo de configuração do Apache (geralmente /etc/apache2/apache2.conf), ao menos um contêiner [Location], onde estará configurado o seu repositório SVN. Claro que você pode ter mais de um [Location], caso seu Apache precise servir vários repositórios ao mesmo tempo. Você também deve ter criado seu arquivos de senhas HTTP, onde a autenticação do usuário será feita.
Você notará que, mesmo com autenticação do usuário (no modo basic authentication, usando a diretiva AuthType Basic), ainda há risco de segurança, pois a senha e os dados não são encriptados, de forma que a senha é enviada em texto puro (plain text) e pode, com certa habilidade, ser capturada por pessoas mal-intencionadas. O outro modo de autenticação (digest), onde a senha é passada como uma soma MD5, ainda tem algumas falhas em seus processos. Sendo assim, a segurança somente estará garantida se seu acesso ao repositório for feito integralmente em conexão segura, via SSL.
Este artigo ensina rapidamente como configurar o SSL que seu Apache já tem (vide artigos anteriores) com o seu repositório SVN.

• Acessando o WebDAV com Conexão Segura no Apache

Suponhamos então que você tenha um contêiner [Location] como este, no seu /etc/apache2/apache.conf:

[Location /repositorio1]
DAV svn
SVNPath /opt/svn/repositorio1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svn/passwd
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
[LimitExcept GET]
Require valid-user
[/LimitExcept]
[/Location]

OBS: Substitua os colchetes por sinais de maior e menor que!!

Este [Location] funciona, mas responde apenas via HTTP, na porta 80. Para ele passar a responder na porta 443, com conexão segura, precisamos de duas coisas (assumindo que as chaves já estão instaladas e configuradas no Apache, conforme mostrado nos artigos anteriores):

1- Proibir o acesso ao contêiner pelo protocolo HTTP (porta 80). Ou seja: forçar o acesso ao WebDAV via SSL. Para tanto, basta acrescentar a linha em negrito:

[Location /repositorio1]
SSLRequireSSL
DAV svn
SVNPath /opt/svn/repositorio1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svn/passwd
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
[LimitExcept GET]
Require valid-user
[/LimitExcept]
[/Location]

OBS: Substitua os colchetes por sinais de maior e menor que!!

A diretiva SSLRequireSSL impede que o acesso a este [Location] seja feita por qualquer outro meio que não via SSL. Existem outras diretivas que podem controlar este acesso, como a SSLVerifyDepth 1, que indica a profundidade (níveis de sub-diretórios) em que o acesso forçado em SSL deve ser aplicado. Evidentemente, informar o número zero "0" irá sugerir toda a árvore de diretórios. Para o nosso caso, esta diretiva não é necessária, pois, sem ela, o SSL já é forçado em todo o repositório, que é o que queremos.
Agora seu repositório está inacessível: não responde mais na porta 80 (o Apache vai informar a mensagem "Forbidden", ou seja, acesso negado), mas ainda não responde na porta 443. Para completar a operação, execute o passo 2, abaixo.

2- Criar um VirtualHost para o acesso seguro via SSL.
Um VirtualHost é um super contêiner do Apache que faz diversas coisas: mapeamento de URLs, redirecionamentos, escolha de portas, criação de regras de acesso, configuração de Aliases, dentre outras coisas, e suporta praticamente qualquer contêiner e diretiva dentro dele. Exatamente por isto precisamos criar um VirtualHost para o acesso à porta 443, conforme mostramos no exemplo:

[VirtualHost 127.0.0.1:443]
Servername localhost
DocumentRoot /var/www
[IfModule mod_ssl.c]
SSLEngine on
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
[/IfModule]
[/VirtualHost]

OBS1: Substitua os colchetes por sinais de maior e menor que!!
OBS2: Substitua o IP 127.0.0.1, que é usado apenas como exemplo, pelo IP de seu servidor!!

O que isto faz?? Bom, vamos aos detalhes:

VirtualHost IP:443 - Significa que você está criando o conjunto de regras específicas para o uso da porta 443, que é a porta configurada para conexão segura por SSL, o chamado protocolo HTTPS.
Servername localhost - É o nome do servidor. Troque o termo "localhost" por um nome válido. Este é usado apenas como exemplo.
DocumentRoot /var/www - É claro que este não é o endereço de seu repositório, mas é um local que vai ser utilizado caso alguém tente ler a URL raíz de seu servidor, por exemplo: https://localhost. Se você informar o endereço físico (diretório no sistema de arquivos) de um de seus repositórios aqui, estará criando uma brecha de segurança para um possível invasor. O local que o DocumentRoot informar não impede que um ou mais [Location] sejam contemplados pelo VirtualHost protegido.
SSLEngine on e demais diretivas do módulo SSL (mod_ssl.c) - responsáveis por ativar efetivamente o SSL nesta porta informada. Por aqui, você nota que é possível, no Apache, servir o SSL em ainda outra porta, diferente da 443. Não sei por que você desejaria isto mas, caso deseje, tenha a certeza de adicionar a diretiva "Listen" com o número da porta desejada. Exemplo: "Listen 400", para a porta 400. Isto não é informado no VirtualHost, mas sim no ports.conf, ou, opcionalmente, no apache2.conf, httpd.conf ou no mods-available/ssl.conf.

Existem outras coisas que você pode pendurar no VirtualHost, como os contêineres [Directory], que poderão ser utilizados especialmente para outros portais e sites que você serve com seu Apache. O fato de existir um contêiner para a porta 443 não impede que exista outro para a porta 80. Desta forma, seu Apache pode servir tanto conexões seguras (SSL/HTTPS) quanto conexões abertas (HTTP na porta 80). Basta configurar direitinho os VirtualHost. Como este artigo é apenas sobre o WebDAV e não um curso de Apache, recomendo que, se este é o seu caso, procure a documentação do Apache para maiores detalhes. Um exemplo mais sofisticado de configuração do VirtualHost pode ser encontrado aqui.

• Configurando o WebDAV com SSL sem usar Location (Somente o VirtualHost)

Esta não é, inicialmente, a minha recomendação, porém provavelmente será mais útil a quem tem apenas um repositório para servir com o Apache e quer configurar o Apache como um servidor dedicado. Um servidor dedicado é aquele que serve a apenas um portal ou serviço, normalmente um que sofra com muitos acessos e grande carga, de sorte a justificar um servidor só para ele. Pode ser o caso de sua empresa, por exemplo, se todos os projetos estão centrados em um único repositório SVN acessado a partir de um único servidor Apache, vindo a sofrer grande volume de acessos.
Bom, neste caso, você pode fazer a configuração toda diretamente no VirtualHost, eliminando o contêiner [Location]. Isto vai ajudá-lo a configurar o repositório diretamente na URL raíz, ou seja, no caminho virtual "/" de seu servidor. Vide o exemplo abaixo:

[VirtualHost 127.0.0.1:443]
Servername localhost
DocumentRoot /var/www
[IfModule mod_ssl.c]
SSLEngine on
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
[/IfModule]
[Directory /opt/svn/repositorio1]
DAV svn
SVNPath /opt/svn/repositorio1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svn/passwd
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
[LimitExcept GET]
Require valid-user
[/LimitExcept]
[/Directory]
[/VirtualHost]

OBS: Substitua os colchetes por sinais de maior e menor que!!

Note que este exemplo é bem semelhante ao primeiro. A diferença é que ele migra praticamente todas as informações que colocamos no contêiner [Location] (referentes à configuração do WebDAV), que ficava diretamente no /etc/apache2/apache.conf, para dentro de um contêiner [Directory]. Este, por sua vez, é disposto dentro do contêiner VirtualHost, em /etc/apache2/apache.conf. Isto provoca que as informações do [Directory] digam respeito ao endereço raíz e poderão ser acessadas pela URL https://localhost/.
Conforme mencionado, é o caso ideal para quem mantém apenas um repositório e tem um Apache exclusivo para o mesmo, embora outros VirtualHost (e contêineres [Directory]) possam ainda ser criados e configurados neste mesmo Apache.

• Conclusões

Foram apresentadas duas técnicas para a configuração do WebDAV no Apache usando SSL: uma mais própria para configurar um único repositório e outra mais apropriada para múltiplos repositórios do SVN. A sua escolha da técnica, bom como qualquer refinamento a ser incluído, deve levar em conta o uso de seu repositório, a carga que ele recebe e a quantidade de repositórios gerenciados pelo Apache. O uso do WebDAV, mesmo via SSL, não exclui que o Apache sirva outras páginas e sistemas.
Espero que este conjunto de tutoriais tenha sido útil!! Lembre-se de que, sempre que possível, é fundamental que você COMENTE!!!

Ignorando Arquivos com o SVN (ou: Onde Coloco o meu .cvsignore no SVN??)

Quem migrou do CVS para o SVN, especialmente aqueles que converteram seus repositórios com as ferramentas existentes e continuaram seus projetos com o novo versionador, talvez tenha notado que, no SVN (ou Subversion), o antigo arquivo ".cvsignore" não produz nenhum efeito... este presente artigo ensina como fazer o SVN aprender a ignorar alguns arquivos que não devem ser versionados e as diferenças entre o SVN e o CVS consoante a este assunto.

• Ignorando Arquivos com o CVS

É famoso e fácil esse truque de ignorar arquivos com o CVS. Basta se criar um arquivo chamado ".cvsignore" na pasta onde os arquivos a serem ignorados ficarão (apenas na pasta, não nas sub-pastas!!). Este deverá ser um arquivo texto, contendo, a cada linha, o nome de um arquivo a ser ignorado (você pode usar caracteres como "*", para designar grupos de arquivos com nomes semelhantes).
Isto faz o cliente (e não o servidor!) do CVS deixar de observar os arquivos listados, mas você, um cara esperto, pode subir o arquivo ".cvsignore" e forçar que todos da sua equipe façam o update do mesmo, de forma que aqueles tais arquivos a serem ignorados serão sempre ignorados em todas as máquinas dos membros de sua equipe e nunca serão enviados para versionamento.
Um exemplo de arquivo .cvsignore é:

cat .cvsignore
*jar
*sh
*bat
*bak
*~

Desvantagens do uso desta técnica são:

1- Você depende de um arquivo local que diga o que ignorar, então o servidor não tem controle sobre isto;
2- Pode ser que dois desenvolvedores com arquivos ".cvsignore" diferentes (ou um desenvolvedor sem o tal arquivo) acabem fazendo filtragens diferentes, o que pode culminar no envio indesejado de um arquivo para o versionamento.

• Ignorando Arquivos com o SVN

Por motivos como o exposto acima, o SVN não utiliza esta técnica (então, não há arquivos ".cvsignore" nem nenhum tipo de ".svnignore"!! Não tente criar este arquivo apenas por força da analogia, pois não funcionará!!).
Para o Subversion, o controle sobre os arquivos a serem ignorados deve estar o tempo todo no servidor, e é adicionado através de uma propriedade de uma pasta. Esta propriedade é criada na pasta específica onde os arquivos serão ignorados e, após a sua criação, a pasta é considerada alterada e necessitará de um commit para efetivação da propriedade no servidor.
Após esta efetivação, os outros membros de sua equipe deverão ver, em seus clientes do SVN, que a pasta foi modificada (porém sem qualquer menção aos arquivos internos desta pasta) e, ao baixarem a nova versão da pasta, automaticamente terão marcada a propriedade responsável por ignorar os arquivos indesejados.
Esta operação gera um número de revisão.

• Como Definir a Propriedade Que Ignora Arquivos no SVN??

A referida propriedade chama-se svn:ignore e pode ser adicionada de várias maneiras, dependendo de seu cliente de SVN, estando sempre relacionada à pasta cujo conteúdo será filtrado (e não a uma pasta raíz... o conteúdo é filtrado na pasta onde a propriedade é definida, e não nas sub-pastas!!). Assim, se você utiliza o terminal, basta digitar, por exemplo:

svn propset svn:ignore .~* articles/

Isto instrui ao SVN que defina a propriedade (propset) chamada svn:ignore com o valor ".~*" para o diretório articles/. Este modelo, por exemplo, força que um diretório chamado articles, supostamente de documentos do Open Office, ignore todos os arquivos temporários do Open Office, que normalmente têm o nome criado a partir da fórmula ".~[nome do arquivo original]#". Agora, faça o commit, para subir ao servidor esta alteração!!
Se você utiliza um cliente gráfico, como o plugin Subclipse para o Eclipse (do qual falamos detalhadamente neste artigo), basta clicar na pasta desejada com o botão direito e escolher a opção Team, sub-opção "Set Property...", conforme mostrado na Figura 01, abaixo (clique para ampliar a figura!!):

Figura 01: Selecionando a opção para criar a propriedade.

Na janela que surgir, escolha a propriedade svn:ignore e digite, na caixa de texto abaixo, todos os tipos de arquivos que devem ser ignorados, podendo usar o caracter "*" à vontade!! Vide Figura 02:

Figura 02: Definindo a propriedade svn:ignore.

Agora, a pasta que sofreu a configuração estará marcada como modificada e você deverá efetivar esta modificação, enviando-a para o servidor (faça um commit!!). Automaticamente, todos os membros da sua equipe de trabalho, após atualizarem seus projetos pelo repositório (ou seja, após fazerem um update), terão suas configurações de ignorar arquivos ajustada!!

Vantagens desta abordagem são:

1- Não há dependência de um arquivo local, o que impede o problema clássico de um desenvolvedor criar ou modificar este arquivo, esquecer de subir para o servidor, e a equipe começar a trabalhar com políticas diferentes de seleção de arquivos para versionamento.
2- Gera mais consistência entre a pasta e os arquivos permitidos para ela, dificultado que alguém burle esta regra, pois todos serão de certa forma forçados a fazer previamente o update da pasta se quiserem inserir ou modificar algum arquivo nela.
3- A definição da propriedade gera um número de revisão, com sua respectiva mensagem, documentando e caracterizando o ato.

Bom, pessoal... espero que este tutorial tenha ajudado a vocês!! Boa sorte!! (Ah!, COMENTEM aí embaixo!!!).

Versionando Seus Dados: Boas Práticas e Dicas

Existe inúmeros servidores de controle de versão, como o CVS e o Subversion (SVN). Este artigo visa sugerir boas práticas para que estes servidores sejam utilizados da melhor e mais confiável maneira. É um artigo abrangente, direcionado tanto para desenvolvedores de programas quanto para usuários domésticos que nada sabem de programação.

• Por Que Versionar Meus Dados??

O versionamento foi criado inicialmente para que equipes de programadores pudessem compartilhar de maneira segura e flexível códigos elaborados na construção de componentes de um mesmo programa. Com o versionamento, tornou-se possível e seguro não só o compartilhamento, como também a recuperação de versões anteriores dos arquivos versionados, ou mesmo a comparação entre as versões de um mesmo arquivo (o chamado diff).
Hoje em dia, com a evolução das tecnologias, como o aumento dos discos rígidos e a facilidade de criação de repositórios na rede (online), tornou-se viável e realmente útil realizar versionamento de qualquer coisa, desde documentos do Open Office, como textos e planilhas eletrônicas, até figuras e códigos de programas. Assim, realmente vale a pena (e recomendo!!) que você versione sua planilha com os endereços e telefones de seus contatos, seus dados de controle de gastos domésticos, sua tese de doutorado, suas fotos da câmera, suas músicas, seus históricos de programas de mensagens instantâneas, os documentos do trabalho, seu livro que vai sair um dia, suas poesias, etc, etc...
O versionamento é capaz de te lhe trazer muitos benefícios, dos quais destaco os seguintes:

1- Cópia de segurança de seus dados (o chamado backup);
2- Organização de seus dados: criação apropriada da estrutura de pastas e melhor escolha dos nomes de arquivos;
3- Armazenamento das versões anteriores dos arquivos, permitindo a recuperação das mesmas ou de parte destas;
4- Comparação entre duas ou mais versões diferentes dos arquivos a partir de programas de diff, presentes hoje na maioria dos grandes aplicativos, como a suíte do Open Office;
5- Edição e manutenção coletiva dos arquivos: várias pessoas mexendo neles ao mesmo tempo não será mais sinônimo de bagunça e perda de dados!!
6- Ferramentas para mesclar dados;
7- Fácil sincronização entre os dados que você produziu e mantém em seus diversos computadores: laptop, máquina do trabalho, máquina de casa, celular, etc..., evitando perdas de arquivos ou perigosas regressões de seus trabalhos devido à acidental sobrescrita de uma versão mais nova por uma mais antiga (que lance a primeira pedra quem nunca cometeu esse equívoco...).

• Como Versionar Tudo Isso??

Existem milhares de controladores de versão. Eu recomendo o Subversion (abreviadamente denominado de SVN), que é bem mais seguro e inteligente que o CVS, além de existir para a grande maioria as plataformas, ser gratuito e livre, extremamente leve, vastamente testado e retestado e ter plugins e clientes das mais diferentes formas e condições.
Existem tutoriais que ensinam como fazer a sua pasta home do Linux ficar automaticamente versionada pelo SVN, de forma que qualquer coisa que você simplesmente salve ali irá automaticamente ser enviada para o servidor. Apesar de ser imensamente prático, eu não recomendo que você faça isto... mas, por quê?? Porque este procedimento gera muitos commits (efetivações) desnecessários no banco de dados do seu repositório versionado, além de tender a que todos eles sejam feitos sem qualquer mensagem descritiva, o que torna difícil a identificação da versão que você quer recuperar, caso seja necessária.
Este tutorial não ensina a instalar o servidor de controle de versão nem a criar repositórios (se é isso que você quer, navegue aqui mesmo, nesse meu ao lado direito, e veja os outros artigos do Pajé que ensinam detalhadamente muitos dos rudimentos destas técnicas, voltados para o SVN), mas sim ensina boas práticas e como explorar melhor o "poder" do versionamento.

• Dicas Para um Bom Versionamento

Seguem abaixo várias dicas que podem ser utilizadas tanto por desenvolvedores de softwares quanto por usuários domésticos, em busca de proteção e compartilhamento de seus dados.

1- Sempre faça commits (efetivações) com mensagens. Embora muitos controladores de versões permitam subir dados sem dizer qualquer coisa a respeito, não se furte ao comentário. Somente assim será possível identificar o conteúdo novo de cada revisão criada. Nem preciso dizer que isto é essencial nas buscas e pesquisas, como comparações, das versões antigas.
1.1- Se seu repositório é compartilhado por pessoas de vários países, somente escreva as mensagens em inglês.

2- Não saia fazendo muitos commits alopradamente!!!! Suba apenas aquilo que está funcionando (ou seja, um código completo, sem erros, ou um documento com uma seção inteira adicionada ou revisada). Faça valer o gesto da criação de uma nova revisão do arquivo!!

3- Se algo ficou pendente no arquivo e você considera que possa ser feito mais tarde, não interferindo diretamente na seção onde você está trabalhando, inclua comentários sobre o mesmo. Em código de programa, normalmente se inclui blocos "TODO", para clamar por código extra (que normalmente serão providenciados em outras seções do programa) ou "FIXME" (normalmente indicando trechos hard coded). Em documentos do Open Office, coloque comentários mesmo (menu Inserir, opção Anotação), aquelas caixas de texto amarelas que guardam uma informação extra sobre um trecho do documento, sem interferir no conteúdo (não inclua os comentários como se fossem parte do documento, por favor!!! Eles usualmente lhe escapam e vão acabar sobrando no texto final, o que fica muito feio para o autor!!).

4- Nunca, mas nunca nunquinha da Silva, comece diretamente a trabalhar em seus arquivos locais!!! Antes de fazer qualquer coisa, sincronize sua base de dados local com o repositório, buscando comparar o que você tem com as versões mais novas dos arquivos e atualizando tudo o que você tem.

5- Evite armazenar o seu repositório no mesmo local onde você sempre trabalha!!!! Se ele está na mesma partição de seu disco rígido (ou até se o repositório fica no mesmo disco rígido onde você trabalha), num momento em que o disco entre em pane ou queime, você perderá tudo do mesmo jeito, seus dados locais e o precioso repositório. Vide soluções para este caso, em ordem de segurança, do menos seguro para o mais seguro:
5.1- Você pode armazenar seu repositório em um outro disco rígido de sua máquina, voltado só para isso (ainda assim, pouco seguro);
5.2- Você pode armazenar seu repositório em um dispositivo externo, como um disco externo ou pendrive (segurança média);
5.3- Você pode armazenar seu repositório em uma área de rede, que fica em um servidor de arquivos, ou seja, uma máquina na sua empresa ou na sua casa com um bom espaço ligada 24 horas por dia e com acesso compartilhado (segurança média);
5.4- Você pode armazenar seu repositório em uma área acessível via SSH (ou outro protocolo qualquer) de um storage, com vários discos rígidos compartilhados com alguma técnica de redundância e/ou espelhamento (altamente seguro, porém é mais uma solução corporativa do que doméstica!!);
5.5- Você pode armazenar seu repositório em uma área virtual fornecida por algum compartilhador, como o Dropbox, que mantém severas rotinas de backup e sela o compromisso de altíssima disponibilidade (altamente seguro, porém é mais uma solução doméstica do que corporativa!!);

6- Evidentemente, faça backups freqüentes de seu repositório!!! Nada adiantará ter toda essa tecnologia e um dia acontecer uma fatalidade... faça backups em meios seguros, como CD, DVD, outros Discos Rígidos, etc, conforme o volume e fluxo de seus dados. Agende seu backup em períodos razoáveis, de acordo com a sua produção.
6.1- PELAMORDEDEUS: teste seus backups com freqüência!!! Mais uma vez insisto: de nada adiantará ter toda essa tecnologia, inclusive o backup, se uma fatalidade ocorrer, você perder tudo, ter de voltar ao backup, e justamente aí descobrir que, por algum motivo, você não consegue recuperar o backup, pois: ou ele foi feito de maneira incorreta, ou ele estava acontecendo de maneira parcial e você nunca notou, ou qualquer outra péssima eventualidade.... teste, e teste periodicamente!!

7- Sempre que terminar ou concluir uma parte completa de seu trabalho, envie para o servidor. Programe sua rotina de trabalho para que, no final do expediente (ou de uma seção de trabalho), você tenha concluído o que você iniciou e esteja apto a subir para o servidor. Como não recomendo que suba nada com erros, com código incompleto, com seções de documento incompletas ou inconclusas e sem anotações, então programe direitinho sua seção de trabalho. Claro que imprevistos acontecem, mas tente minimizar isto e deixar o mínimo possível de novidades locais, para garantir a segurança de seus dados e evitar conflitos nas próximas sincronizações, caso ou outros membros da sua equipe trabalhem nos mesmos arquivos que você durante o intervalo entre uma seção e outra de seu trabalho.

8- Por questões de zelo e cuidado, sempre suba documentos e códigos bem formatados e ajustados. Melhora a compreensão, especialmente se você não trabalha sozinho...


Bom, pessoal... em linhas gerais, é isto que quero dizer. Espero ter ajudado!! Qualquer coisa: COMENTEM!!!

Como Acessar o SVN via HTTP

Este artigo apresenta, de forma resumida, como configurar seu repositório do Subversion para ser acessado usando o protocolo HTTP. Esta configuração é apenas um dos três modos de operação do SVN (mais sobre os outros modos e uma ampla discussão sobre as características, vantagens e desvantagens de cada um encontra-se em nosso outro artigo, aqui. Se o seu caso for aprender a instalar o SVN tunelado por SSH, então veja também este outro artigo aqui). Supõe-se, neste artigo, que o SVN já esteja propriamente instalado e configurado na máquina servidora. Supõe-se que você já tenha um cliente instalado em máquina local, para fins de testes. Caso não saiba instalar um, sugiro consultar nosso outro artigo, aqui.

• Instalação do Apache

Fazer o SVN ser acessado por HTTP necessita de um servidor Web, já que este protocolo não é o padrão para o SVN. A sua função é colocar-se como intermediário entre o usuário e o repositório versionado, executando, em linhas gerais, as seguintes tarefas:

- Receber as requisições HTTP do cliente;
- Validar o usuário do cliente com base de dados de usuário própria;
- Traduzí-las para o SVN, usando usuário próprio do sistema operacional;
- Coletar as respostas do SVN;
- Traduzí-las de volta para o protocolo HTTP;
- Enviá-las para o cliente.

O servidor web utilizado para tunelar o SVN através do protocolo HTTP é o Apache Web Server 2; o diálogo entre o Apache 2 e o SVN é possível graças a um módulo especial do Apache, o WebDAV. O comando a seguir instala o servidor HTTP e o módulo do webDAV:

apt-get install apache2 libapache2-svn

Após este comando, o Apache 2 será instalado e inicializado, bem como todos os módulos padrão. Após a instalação do módulo do webDAV, ele será automaticamente inicializado. Caso queira se certificar a respeito desta instalação, verifique se surgem as seguintes linhas:

Módulos padrão:
Enabling site default.
Enabling module alias.
Enabling module autoindex.
Enabling module dir.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module status.
Enabling module auth_basic.
Enabling module deflate.
Enabling module authz_default.
Enabling module authz_user.
Enabling module authz_groupfile.
Enabling module authn_file.
Enabling module authz_host.
Enabling module reqtimeout.

Módulos do webDAV:
Enabling module dav.
Enabling module dav_svn.

Para confirmar quais os módulos estão ativos, basta ler o diretório onde os links simbólicos para os módulos ativos ficam:

# links para os módulos ativos
ls /etc/apache2/mods-enabled/

# todos os módulos instalados
ls /etc/apache2/mods-available/

# onde os arquivos executáveis realmente ficam...
ls /usr/lib/apache2/modules/

• Configuração do Apache 2

Criação do Arquivo de Senhas

Para que o seu repositório seja acessado com validação de usuário, é preciso que os usuários sejam previamente criados com suas senhas. Caso o seu repositório seja sempre público, este passo se tornará desnecessário.
Os usuários aqui referidos são usuários HTTP, e não usuários do sistema da sua máquina. Estes usuários ficam em um arquivo específico, onde se encontram com suas senhas. Felizmente, o Apache nos fornece uma ferramenta para a criação (e inserção) destes usuários, o htpasswd.
A criação de um arquivo novo, contendo seu primeiro usuário e senha, pode ser feita com o seguinte comando:

htpasswd -c /opt/svnrepos/repo1passwd admin
ou
htpasswd -c /opt/svnrepos/repo1passwd admin [senha]

Onde "admin" pode ser qualquer nome de usuário, e [senha] pode ser qualquer senha. Caso a primeira opção seja digitada, o comando perguntará a senha e pedirá que a repita antes de concluir a execução. Note que a segunda opção armazena a senha no histórico de comandos do shell, então tome cuidado ao usá-la!!
A opção “-c” cria o arquivo de senhas. Sem esta opção, o usuário informado é adicionado ao arquivo referenciado, que já deve existir.
A opção “-d” remove um usuário.

Após o comando, o arquivo passa a existir, com uma linha, onde o nome e a senha do usuário “admin” são separados com o caracter “:”, exatamente como o Linux faz em /etc/passwd. Observe:

cat /opt/svnrepos/repo1passwd
admin:k3ir2JUfTSAr6

Note que a senha está segura e criptografada. Existem opções no htpasswd para que ela não seja criptografada ou para selecionar qual algoritmo dentre os disponíveis deve ser usado em sua criptografia. Mais detalhes sobre o htpasswd pode ser acessado em sua página man ou com o parâmetro “-h”.

• Configuração do Repositório no Apache

Neste momento, supõe-se que você já tenha um repositório criado no seu sistema de arquivos (tarefa normalmente feita com a ferramenta svnadmin).
Para informar o seu repositório para o Apache, é preciso editar o seguinte arquivo:

vi /etc/apache2/apache2.conf

Neste arquivo, deve-se incluir (em especial, para o bem do administrador de sistemas, no final do arquivo, com um comentário indicando a que veio o bloco de linhas!!), para cada repositório, um conjunto de linhas como este aí embaixo, capaz de informar a localização do repositório e a configuração de acesso ao mesmo:

[Location /repo1]
DAV svn
SVNPath /opt/svnrepos/repo1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svnrepos/repo1passwd
Require valid-user
[/Location]

OBS: Substitua os colchetes por sinais de maior e menor, formando a tag corretamente!!

Bom, o que significa isto?? Bem fácil, acompanhe-me:

- Location: É a localização virtual do repositório (no formato de tag, que, para o Apache, recebe o nome de "Contêiner"). No caso acima, ele será acessível pelo endereço "http://[servidor]/repo1";
- DAV svn: Usar o módulo dav, direcionado para o SVN;
- SVNPath: Caminho real do repositório no sistema de arquivos;
- AuthType Basic: Tipo de autenticação. Sendo Basic, o acesso é permitido apenas a usuário devidamente autenticados. Note que esta autenticação não garante encriptação na hora de fornecer os dados sensíveis de usuário e senha pela rede. Dentro de uma rede local, isto pode não ter o menor problema. Porém, não faça assim se o seu repositório é visível pela internet!! Se este for o caso, então cogite usar uma chave de encriptação e proteger a conexão inteira por SSL, utilizando, na verdade, o protocolo HTTPS. Verifique os links de nossos artigos sobre o assunto deixados na conclusão deste artigo...
- AuthName: Nome de identificação do repositório, que aparecerá na janela de login do usuário e no nome do repositório, após o projeto ser baixado via checkout;
- AuthUserFile: Define qual o arquivo de senhas de usuários HTTP, criado pela ferramenta htpasswd, do Apache, conforme mostrado mais acima.
- Require valid-user: Exige login e senha de um usuário válido, independente da ação requerida.

Concluída a configuração, podemos finalmente reiniciar o Apache:

/etc/init.d/apache2 restart

Note que o Apache faz todo o acesso a disco a partir de seu usuário próprio (em geral, o www-data). Assim, é preciso que o seu repositório do SVN, assim como o diretório “db” e todo o conteúdo deste estejam acessíveis a este usuário. Normalmente, basta digitar os seguintes comandos:

Trocando o usuário nos arquivos e diretórios necessários:
chown www-data /opt/svnrepos/repo1
chown -R www-data /opt/svnrepos/repo1/db

Trocando o grupo nos arquivos e diretórios necessários:
chgrp www-data /opt/svnrepos/repo1
chgrp -R www-data /opt/svnrepos/repo1/db

• WebDAV: Configurando Diferentes Permissões de Acesso (ou: Como acessar anonimamente o repositório?)
  

O exemplo acima é apenas um exemplo simples. Em alguns casos, porém, é interessante que seu repositório trabalhe com diferentes políticas de permissão de acesso, dependendo da ação (requisição) sendo solicitada. Exemplo: se o seu projeto é de código livre, talvez interesse manter o repositório aberto para leitura (update ou checkout) por toda a comunidade, sem exigir login de usuário e senha, mas, por segurança, manter a exigência de autenticação (usuário e senha) se a ação implicar alguma modificação no repositório (alterar aquivos, modificar propriedades, apagar ou adicionar arquivos, etc.). Assim, você tem seu repositório protegido, ou seja, somente a equipe autorizada é capaz de mexer nele, porém qualquer pessoa, de qualquer lugar do mundo, poderá baixar, a qualquer momento, o último estado (snapshot) do seu sistema.
Para realizar esta proeza, é bem simples. Primeiramente, devemos retirar a linha "Require valid-user", que exige autenticação irrestritamente, sem considerar o tipo de ação. Depois disso, devemos acrescentar as tags "Limit" ou "LimitExcept". A tag "Limit" contendo uma linha "Require valid-user" informa as ações que devem exigir autenticação. A tag "LimitExcept" contendo a mesma linha informa as ações que devem ser excetuadas desta regra, ou seja, que não exigirão autenticação. As duas tags podem ser adicionadas, mas isto será redundante. Em geral, prefira uma das duas. É comum se trabalhar apenas com a LimitExcept, para a configuração ficar menos verbosa.
Em resumo, para a situação proposta, a configuração ficaria:

[Location /repo1]
DAV svn
SVNPath /opt/svnrepos/repo1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svnrepos/repo1passwd
# Require valid-user # Retirada esta linha!!
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
# Ou então, em lugar do Limit:
[LimitExcept GET PROPFIND, OPTIONS, REPORT]
Require valid-user
[/LimitExcept]

[/Location]

OBS1: Substitua os colchetes por sinais de maior e menor, formando a tag corretamente!!
OBS2: As ações incluídas dentro das tags Limit e LimitExcept são, muitas vezes, métodos HTTP. A listagem completa deles pode ser obtida aqui.
OBS3: Se você incluir no LimitExcept apenas o método GET, seu repositório será acessível anonimamente via HTTP, ou seja, do navegador, mas não poderá ser baixado de um cliente SVN sem nome de usuário e respectiva senha.

• Conclusões

O acesso via webDAV é muito mais interessante para grandes equipes, pois protege mais o servidor, criando, através do Apache 2, uma camada de abstração entre o usuário e o repositório. Também esconde onde é o local exato em que o repositório está e quem realmente pode acessar a máquina servidora.
Existem, no entanto, muitas outras maneiras de configurar o webDAV, como:

- Forçá-lo a ser acessado apenas por HTTPS (imprescindível se seu repositório está aberto à internet). Se é isto que procura, visite nossos artigos Criando Certificações SSL com OpenSSL e Configurando o Apache com SSL;
- Abandonar o arquivo de senhas do Apache e configurá-lo para usar autenticação a partir de dados de uma tabela do MySQL;
- Dentre muitas outras coisas...

Todos estes tópicos fogem ao escopo deste pequeno artigo, mas espero ter fôlego para abordá-los tão logo, aguardem!!
Claro, como sempre, não devemos nunca nos esquecer do quanto é importante que COMENTEM!! ;-)

Instalando o Plugin do SVN no Eclipse

Para quem usa o Eclipse e o SVN, provavelmente não é novidade que se tenha algum problema ao instalar o plugin... o fato é que, apesar de o Eclipse ser uma excelente IDE (tanto para desenvolvimento Java como para Web, C, C++, Phyton, e milhares de outras linguagens), ele não vem com um plugin para o SVN por padrão (vem apenas com o plugin do CVS), e a gente tem que instalar manualmente o plugin de nossa preferência.
Este artigo ensina como se instalar o plugin Subclipse, que considero ser o mais fácil de se instalar e usar. As instruções foram testadas no Eclipse Galileo e Helios, utilizando o SVN Server versão 1.6 no servidor (todas as versões mencionadas são bem atuais, no momento de criação deste artigo). Note que tratamos, aqui, apenas da parte cliente. A parte servidora, ou seja, a instalação e configuração do SVN, já foi tratada em diversos outros artigos deste portal, como este e este.
É importante saber qual versão do SVN instalada no servidor que você usa, uma vez que os clientes de SVN, como o plugin do Eclipse, que funcionam localmente, precisam de um driver para falar com o servidor, e este driver é específico para cada versão.

• Como descobrir a versão de meu SVN Server??

Bem simples. Acesse a máquina servidora onde o seu Subversion (servidor) está instalado e digite "svnserve --version" ou "svnadmin --version". Observe a primeira linha da saída de texto:

$ svnserve --version
svnserve, version 1.6.6 (r40053) compiled Dec 12 2009, 05:06:12

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository back-end (FS) modules are available:

* fs_base : Module for working with a Berkeley DB repository.
* fs_fs : Module for working with a plain file (FSFS) repository.

Cyrus SASL authentication is available.

• Preparando para Instalar o Plugin do Eclipse

Para todas as operações daqui para frente você deverá ter um JDK (Java Development Kit) instalado em sua máquina. Caso não o tenha, você poderá baixá-lo gratuitamente aqui.
Supomos que você baixou o Eclipse do site oficial (http://www.eclipse.org/), e que é a versão correta para seu sistema e sua arquitetura (32 ou 64 bits). Recomendo que baixe a compilação mais completa, com as ferramentas de JEE, uma vez que elas poderão ser muito úteis, mesmo que você inicialmente não vá desenvolver para web. Agora basta descomprimir o Eclipse e colocá-lo em uma pasta acessível.
Para rodar o programa, basta rodar o seu executável dentro de sua pasta padrão (não é necessária qualquer processo de instalação prévio):

cd eclipse
./eclipse

A instalação do plugin é feita de dentro do Eclipse mesmo, acessando o menu HELP, opção "Install New Software...", conforme mostra a Figura 1.

Figura 1: Menu Help do Eclipse Helios.

Acessando esta opção, entramos na ferramenta de atualização e instalação de novos plugins para o Eclipse. Virtualmente qualquer coisa pode ser instalada ou removida de seu Eclipse nesta tela. Portanto, tome cuidado ao mexer nestes componentes, pois não é tão difícil "quebrar" as dependências dos plugins e corromper o seu Eclipse.

• Instalando o Subclipse, SVN Plugin para o Eclipse

Na tela de instalação de novos plugins, alcançada no item anterior, precisamos adicionar o repositório na rede onde encontraremos o plugin de que precisamos. Alguns repositórios já existirão na lista de repositórios desta janela, mas são os repositórios padrão do Eclipse, e não de outros plugins desenvolvidos por terceiros. Note que, nestes repositórios padrão, existe o plugin Subversive, que tem funcionalidades análogas ao Subclipse, sendo uma alternativa a este. Nunca instale os dois!! Este artigo, contudo, limita-se apenas ao Subclipse.
O repositório correto poderá ser encontrado na própria página do Subclipse, item Download and Install. Para ajudá-lo, já copiei o endereço do repositório aqui:

http://subclipse.tigris.org/update_1.6.x

Este endereço é acrescentado clicando-se no botão "Add". Uma vez acrescentado, o repositório é lido (se você estiver conectado à internet, claro!!), e as opções aparecerão na janela principal. Vide Figura 2 (clique para aumentar!).

Figura 2: tela de atualização e instalação de novos plugins do Eclipse, com o repositório do Subclipse adicionado e sendo lido.

Neste momento, basta se saber selecionar os itens corretos e deixar que o próprio Eclipse encontre os plugins, baixe-os e instale-os automaticamente para você!! Assim, para que tudo funcione, selecione os itens:

Aba "Subclipse", item "Subclipse";
Aba "Subclipse", item "Subversion Client Adapter";
Aba "Subclipse", item "SVNKit Client Adapter".

E, para o driver do subversion:
Aba "Core SVNKit Library", item "SVNKit Library".

- Clique em "Next";
- Confirme os plugins, clicando em "Next" novamente;
- Aceite os termos da licença e conclua a operação, aguardando o término do download.

Após o download e instalação completos, o Eclipse pedirá que seja reiniciado. Procure reiniciar apenas se seus trabalhos estão todos salvos.
Se, em algum momento deste procedimento, surgir uma mensagem dizendo que você está instalando um software que não foi verificado ("Warning: You are installing software that contains unsigned content. Blá blá blá blá..."), ignore-a. O procedimento está correto, a despeito disto...

• Testando a Instalação

Se o Eclipse reiniciou corretamente, provavelmente estará tudo pronto. Para verificar se o Subclipse foi instalado corretamente, selecione a perspectiva que lhe é característica: acesse o menu WINDOW, opção "Open Perspective". Selecione "Other" e escolha a perspectiva "SVN Repository Exploring", exatamente como está na Figura 3:

Figura 3: Abrindo a perspectiva do Subclipse.

Esta perspectiva deve existir na lista. Caso não haja, alguma coisa ficou faltando...
Abrindo a perspectiva, você poderá instalar um repositório, seguindo o item abaixo.

• Instalando um Repositório

Um repositório é o local remoto onde está o banco de dados do SVN, contendo seus dados versionados. Vide os tutorias anteriores do Pajé sobre SVN para aprender mais sobre repositórios, SVN e a parte servidora (referenciados no caput deste artigo).
Para instalar um repositório, abra a perspectiva do SVN (conforme mostrado no item anterior) e clique com o botão direito no view "SVN Repositories". Selecione a opção "New" e sub-opção "Repository Location". Surgirá uma janela pedindo o local do repositório. Complete com os dados que você tem a respeito de seu repositório. Logo depois, uma nova janela perguntará dados adicionais, como o nome do usuário, a senha do usuário e a porta que deve ser acessada no servidor. Complete todas estas informações com os dados corretos da configuração de seu servidor (ou pergunte ao administrador da sua rede como ele configurou isso tudo...).
Uma última tela, que surge apenas no primeiro acesso, pede que você confirme o recebimento da chave de segurança, caso a conexão seja segura. É possível que surja, ainda, outra tela pedindo que repita o nome do usuário. Estas duas perguntas podem ou não ocorrer, dependendo da situação do seu servidor. Responda "Yes" para a primeira e complete a segunda sem sustos com os dados que você já tem.
Prontinho!!! Seu repositório está na lista!! Clique no ícone ao lado esquerdo do endereço, para abri-lo, escolha o projeto que deseja baixar e clique com o botão direito em cima da pasta, selecionando o comando checkout. Isto baixará seu primeiro projeto com esta instalação do cliente SVN.

Boa sorte!! Espero ter sido detalhista o suficiente para que todos que venham a este artigo consigam fazer a instalação com sucesso!! Lembrem-se que, como sempre, em qualquer artigo deste portal, é fundamental que COMENTEM!!

Fazendo Backup de um Repositório SVN

Um repositório do SVN é, na verdade, um banco de dados, embora tendo suas próprias peculiaridades. Assim, ele pode sofrer backup e pode ter seu conteúdo restaurado, total ou em parte. Este artigo ensina apenas a fazer backup do repositório. Há outros artigos nossos com outros tutoriais sobre o SVN que podem ser consultados: como configurar o SVN por túnel de SSH, os modos de configuração do SVN; configurando o SSH para atuar com o SVN.
Cada repositório SVN tem uma variável numérica que é incrementada a cada novo commit (efetivação), denominada "revision". Quando se faz backup, é interessante saber-se em qual número está o revision, ou para contabilizar a quantidade de alterações que foram enviadas, ou mesmo para saber se houve mudanças realmente desde o último backup. Para se obter o número da revisão mais recente, utilize o seguinte comando:

svnlook youngest [path e nome do repositório]

Exemplo:
$ svnlook youngest /var/svn/repo15
237
$

O comando anterior responde apenas o número da revisão, de forma que sua saída pode ser colocada diretamente em uma variável de um script. Para se obter mais informações sobre quem é o autor da última revisão e quando ele fez o commit, utilize o comando:

$ svnlook info /var/svn/repo15
fulano
2010-04-21 23:48:41 -0300 (Qua, 21 Abr 2010)
48
Esta é a mensagem que o autor deixou na revisão.

As linhas da resposta são: autor, data da revisão, número de caracteres da mensagem e a mensagem da revisão.
Ou, para inspecionar uma revisão anterior específica, use:

$ svnlook info /var/svn/repo15 -r 200
[sendo 200 a revisão antiga que se deseja inspecionar]

• Backups Completos

O backup completo pode ser feito com o segunte comando:

$ svnadmin dump /var/svn/repo15 > repo15.r237

Isto fará o backup completo do repositório e o colocará no arquivo "repo115.r237", que pode ter o nome que você desejar. É claro que, quanto maior o repositório, mais lenta esta operação e maior será o arquivo (embora o arquivo de backup costume ser menor que o repositório em si). Muitas vezes, é isso mesmo que desejamos. No entanto, é possível se fazer backup de parte do repositório, a partir de números de revisão informados. Outra forma de backup pode ser:

Fazendo uma cópia direta do repositório para outro, que ficará idêntico ao primeiro:

svnadmin hotcopy /var/svn/repo15 /var/svn/repo16
[funciona exatamente como um comando "cp -r"]

Nesta opção, se você usa o Berkeley DB, você pode dar uma "limpada" nos arquivos de log que não são mais usados, diminuindo o tamanho do repositório. Para tanto use esta opção:

svnadmin hotcopy --clean-logs /var/svn/repo15 /var/svn/repo16

O novo repositório criado é completamente funcional e pode inclusive sofrer dump!!

• Backups Parciais

Utilize o seguinte comando, para fazer backup de apenas uma faixa de revisões desejada:

[backup apenas da revisão 200]
$ svnadmin dump /var/svn/repo15 -r 200 > repo15.r200

[backup apenas da revisão 100 a 200]
$ svnadmin dump /var/svn/repo15 -r 100:200 > repo15.r100-200

Se o seu repositório é gigantesco, é possível que se crie vários arquivos de dump separados. Para tanto, deve-se usar a opção "--incremental". Exemplo:

$ svnadmin dump /var/svn/repo15 -r 0:1000 > dumpfile1
$ svnadmin dump /var/svn/repo15 -r 1001:2000 --incremental > dumpfile2
$ svnadmin dump /var/svn/repo15 -r 2001:3000 --incremental > dumpfile3

• Recuperando o Backup

Como dizem as boas normas de segurança: não basta fazer o backup, mas é preciso se TESTAR O BACKUP!! Assim, vamos recuperar o backup para o repositório. Sem saber isso, de que valeria tê-lo, não é mesmo??

svnadmin load /var/svn/repo16 < repo15.r237

Isto fará um monte de commits, exatamente como seus autores o fizeram, alimentando o novo repositório com o conteúdo de dump do arquivo de backup.
Um backup direto pode ser feito sem a necessidade de arquivo de backup, da seguinte maneira:

svnadmin dump /var/svn/repo15 | svnadmin load /var/svn/repo16

Bom, espero ter ajudado com todas estas dicas... se este artigo te ajudou, atrapalhou, resolveu seu problema ou acabou de vez com sua vida, simplesmente: COMENTE!!!!

Os Modos de Configuração do SVN (Server Configuration)

O SVN (ou Subversion) é um controlador de versões dentre os mais populares, que pode ser usado não só por desenvolvedores, mas por qualquer um que queira fazer cópias de segurança versionadas de seus arquivos de trabalho, quaisquer que sejam estes.
Este artigo explana sobre os 3 modos de configuração do servidor. Note que nossa intenção não é ensinar como se configura cada modo detalhadamente, mas apenas descrever e caracterizar o seu uso, para contribuir na escolher mais apropriada. Há um outro artigo contendo um tutorial de configuração mais avançado, que pode ser acessado aqui.

• Modo Serviço

Este é o modo mais simples e fácil de configurar. Muito possivelmente deve ser o primeiro a ser testado, para quem está configurando o subversion pela primeira vez. Neste modo, o SVN entra em cena como um serviço (deamon) e fica rodando ininterruptamente, esperando por requisições.

Suas principais características: fácil e rápido de configurar, funciona mais rápido, não usa senhas nem configuração de contas no SVN.

Como funciona?
O administrador inicia o SVN no boot do linux, como um serviço, ou digitando o comando:

svnserve -d

(-d de deamon, para iniciar o serviço). Lembre-se de liberar no firewall a porta padrão: 3690, ou especifique outra porta, com as opções --listen-port= e --listen-host= no servidor e no cliente svn.
O usuário deve ter uma conta no sistema linux e vai usar a sua conta para acessar o serviço. O acesso deve usar o protocolo svn://, como no exemplo:

svn checkout svn://maquina/opt/svn/projeto

Desvantagens: todo mundo que vai usar precisa ter uma conta no sistema!! Além disso, este modo expõe o caminho do repositório, não tem encriptação ou qualquer forma de segurança, não exige senhas e está sujeito a problemas de permissão de arquivos e diretórios (que vira rapidamente um verdadeiro inferno, mesmo para poucos usuários!!).

Recomendamos para situações muito simples, como:
- Um usuário que quer manter um backup mais ou menos constante de algumas pastas de seu diretório de trabalho (em outra partição do HD ou outro local externo qualquer, como um HD externo ou um super pendrive) .
- Pode ser usado por grupos muito pequenos de desenvolvedores, como um grupo da faculdade, um grupo de colegas, etc., que resolveram montar um servidor a partir de uma máquina antiga para desenvolver um projeto único e específico, num prazo pequeno e temporário.

Nestes casos, não se perde tempo com configurações sofisticadas e não se deixa de aproveitar as incríveis vantagens de se ter o trabalho todo versionado. Não esqueça de fazer backups constantes e de procurar manter o repositório em um local diferente, como outra partição ou outro HD.

• SVN sobre SSH

Esta é uma opção semelhante à anterior, porém com a segurança dos dados transmitidos e recebidos sempre sobre um túnel de SSH. Ela é possível porque o SSH permite que seja passado, via linha de comando, um argumento contendo o comando a ser chamado após aberta a conexão. Isto provoca um tunelamento: o SSH abre a conexão, roda imediatamente o comando (o svnserve -t) e fecha automaticamente a conexão, depois que o comando terminou de executar.
Nesta opção, o SVN não precisa ser carregado na memória como serviço. Na verdade, ele é carregado com a opção "-t" (de tunnel) e encerrado a cada requisição. Todo o tráfego de dados ocorre pela entrada e saída padrão, via SSH.
O servidor pode ser acessado pelo protocolo svn+ssh://, como no exemplo:

svn checkout svn+ssh://usuario@maquina/opt/svn/projeto
usuario@maquina's password: ******

Importante:
- É preciso liberar a porta do firewall para o SSH tornar-se acessível.
- O segredo deste modo está na configuração correta do SSH, que não poderá enviar mensagens de boas-vindas, pois, como o tráfego é via entrada e saída padrão, estas mensagens vão gerar erros de interpretação no SVN. Um artigo que escrevi ensinando a configurar o SSH para o SVN funcionar corretamente pode ser encontrado aqui.
- Todos os usuários precisam ter contas no sistema linux do servidor e, portanto, é preciso que se tome muito cuidado com as permissões do usuário para acessar o repositório.

Recomendamos para:
- Grupos de desenvolvedores, em locais diferentes, que acessam o servidor pela internet ou intranet.

• Modo WebDAV: Usando o Serviço HTTP ou HTTPS do Apache

Este é o modo mais sofisticado, mais flexível e seguro, sendo largamente utilizado, especialmente para grandes projetos com inúmeros desenvolvedores.
Funciona da seguinte maneira: apenas um usuário vai realmente acessar o subversion. Este usuário será utilizado pelo servidor HTTP Apache, pois este servidor pode incluir um módulo que suporta o protocolo WebDAV/DeltaV, uma extensão do HTTP que permite a usuários autenticar-se e autorizar-se para manipular arquivos remotamente, de forma colaborativa. O usuário remoto apenas faz as chamadas HTTP para o Apache, que as traduz para o SVN. Este protocolo pode, obviamente, ser encriptado via SSL, tornando o tráfego mais seguro.

Vantagens:
- Não é preciso criar contas locais para os desenvolvedores;
- É possível se obter todas as vantagens do servidor HTTP Apache, como a encriptação via SSL, uso do Apache Logging e uma navegação gráfica pelo repositório na tela do navegador;
- O repositório pode ser montado como um dispositivo (drive) de rede;
- Pode ser integrado com LDAP, Active Directory, NTLM e congêneros.

Desvantagens:
- Certamente, é muito mais lento, devido à complexidade e à multiplicidade de camadas;
- É muito mais complexo de se configurar;
- Necessita de um servidor mais poderoso, para rodar o SVN e o Apache com todos os requisitos do WebDAV e suportando múltiplas Threads sem perda de desempenho (o módulo mod_dav_svn do Apache necessita do Apache 2).

• Finalizando...

Uma excelente tabela comparativa entre os 3 modos pode ser encontrada aqui.

- Os seus dados estão sempre no repositório, e não no SVN. O repositório pode sofrer Dumps e backups, podendo ser acessado de diferentes formas e modos. Seus dados podem ser exportados e importados para outros repositórios. Portanto, começar usando um modo mais simples não o impede de, mais tarde, reconfigurar o SVN e migrar para o Apache com WebDAV.

- Preocupe-se em escolher o modo que mais se encaixa no seu contexto de trabalho: não vale a pena perder horas instalando e configurando corretamente o Apache 2, o módulo DAV e o SVN para um projeto muito pequeno e de poucos desenvolvedores. Por outro lado, um projeto grande e importante não pode ficar sujeito a criação de muitas contas no servidor, problemas de permissão e acessos sem segurança...

- O que quer que você faça: sempre mantenha rotina de backup e, se possível, use o repositório em outro local diferente da partição ou disco onde está instalado seu sistema. Se algo der errado e seu sistema de arquivos se corromper, os dados estarão sempre seguros...

Configurando o SVN com Tunelamento por SSH

O SVN, ou subversion, é um dos mais utilizados controladores de versão da atualidade. Muito estável, leve e seguro, (além de gratuito!) está presente nas redes de inúmeras importantes empresas e máquinas pessoais. É também um sistema flexível que permite diversos modos de operação; a saber: diretamente, via conta linux; acesso via túnel de SSH; acesso via HTTP e porta 80. Este artigo trata de todos os passos necessários para configurar seu SVN para ser acessado via tunelamente por SSH. Uma análise detalhada sobre as características, vantagens e desvantagens de cada um dos três modo pode ser encontrada no artigo anterior desta série, clicando-se aqui. Importa que leia um artigo nosso que trata da configuração do SSH para usar o SVN: Alterando ou Desabilitando as Mensagens do SSH.

• Criando um Repositório do SVN
  

Os dados versionados, no SVN, ficam em repositórios. Você pode ter quantos repositórios quiser, e cada repositório pode ter vários diretórios (projetos) com arquivos e subdiretórios dentro. Cada repositório tem uma variável chamada revision, que é um inteiro, iniciado em 0 (zero) com a criação do repositório, e que sofre incremento a cada vez que uma nova revisão de um ou mais arquivos é adicionada ao repositório.
Para criar o repositório, basta digitar:

svnadmin create --fs-type bdb [nome_do_repositorio]

o argumento --fs-type indica qual tipo de sistema de arquivos vai ser utilizado. Existem dois tipos: o bdb e o fsfs. Os dois funcionam muito bem, mas têm pequenas diferenças. Sugiro o bdb (Berkeley DB). Você pode achar mais informações sobre este detalhe aqui.

Note que o seu repositório é um diretório com uma determinada estrutura:

$ ls
conf db format hooks locks README.txt

Não precisamos mudar quase nada aqui, apenas um diretório: o diretório "db".

• Tornando o Repositório SVN Acessível

Agora que já temos o repositório, vamos seguir os seguintes passos para terminar a configuração:

1- É preciso que todos os usuários que vão usar o SVN estejam no mesmo grupo do sistema (UNIX Group). Vamos supor que nós criamos uma conta de usuário para cada usuário e um grupo chamado "svnusers", e adicionamos todos os usuários a este grupo. Foge ao escopo deste artigo ensinar como manipular contas no Linux, mas você pode achar (de forma bem detalhada!) tudo o que precisa bem aqui.

2- Agora vamos dizer para o sistema que o diretório "db" do nosso repositório e todos os seus arquivos devem estar liberados para leitura e escrita por todos os usuário do grupo "svnusers". Este passo é importantíssimo, pois evitará os famosos problemas de permissão de leitura e escrita... note que é importante fazer o procedimento não só para o conteúdo do diretório "db", mas também para o próprio diretório, pois, durante o uso, o svn tenta criar alguns arquivos novos no diretório "db".

Mudando o grupo dono do diretório "db" e seus arquivos:

cd [diretório_do_repositório]
chgrp svnusers db
cd db/
chgrp svnusers *

Adicionando-lhes permissão de leitura e escrita para o grupo "svnusers":

cd [diretório_do_repositório]
chmod g+rw db
cd db/
chmod g+rw *

Beleza, você venceu os passos principais!!!

• Testando o Acesso ao Repositório SVN

1- Se você vai acessar o SVN pelo SSH, então é preciso que o SSH esteja instalado, rodando e configurado para receber conexões. É preciso também que ele não emita mensagens de boas-vindas, pois isto irá confundir o cliente do SVN, que vai interpretar o texto como erro de leitura de dados e vai interromper a conexão. Sobre como fazer isto tudo, já deixei um artigo prontinho e bem detalhado aqui.
2- Verifique o firewall de sua máquina para não bloquear nem a porta do SVN (a porta padrão é 3690, mas pode estar configurada qualquer outra porta) nem a porta do SSH (a padrão é a 22, mas igualmente pode estar configurada para qualquer outra).
3- Configure seu cliente SVN para acessar o repositório pelo seguinte endereço:

svn+ssh://[nome_ou_ip_da_máquina]/[caminho_completo_do_repositório]

Exemplos:

svn+ssh://192.168.0.1/opt/repositorio
svn+ssh://server01/var/bin/svnrepos/repositorio32
svn+ssh://maquina.dominio/opt/repositorionovo


Bom, encontrei muitos tutoriais incompletos sobre o assunto, e alguns que, embora completos, não detalhavam o porquê das coisas, dificultando a vida do administrador... assim, espero ter ajudado com este humilde tutorial!! Por isso... COMENTEM!!!!