Ontem, num curta sessão de manutenção dos meus repositórios de Subversion, senti necessidade de reorganizar algumas, como creio ser “normal” ao fim de algum tempo. Tendo a organizar o meu SVN como múltiplos repositórios, um por projecto. Dentro de cada repositório tenho os diversos projectos de classes, sites ou aplicações associados. Tenho assim vários repositórios contextualizados e mais pequenos, em vez de um repositório geral com diversos projectos. A única dificuldade que apresenta é o backup / dump que obriga a manter um script com a lista de comandos de “svnadmin dump” para cada repositorio individual.

Também, apenas agora começo a usar a estrutura de pastas típicas do SVN – /trunk, /brenches e /tags, porque só agora tive necessidade de usar tags para marcar algumas situações. Mover as pastas dentre do repositório para incluir esta alteração é bastante simples, e com o ToirtoiseSVN no server, é drag n’ drop.

Durante a reorganização, senti necessidade de mover alguns repositórios – essencialmente de projectos de testes – e uni-los num só repositório contextualizado. Mover pastas dentro de um repositório é muito simples, usando o commando svn move ou usando o RepoBrowser do ToirtoiseSVN Repo Browser. Mas entre repositórios é um pouco mais elaborado. é preciso efectuar o dump do repositórios, e recarrega-lo no novo repositório, preferencialmente indicando a nova pasta para a qual deve ser carregada. A vantagem é que o histórico de alterações é conservada (sofre apenas uma renumeração).

Para fazer o dump, o comando é:

svnadmin dump d:\repoPathToMove > d:\backupFolder\repoName.dump

Para carregar o dump criado:

svnadmin load d:\pathToNewRepo --parent-dir InternalFolder < d:\backupFolder\repoName.dump

De notar a opção –parent-dir onde indico a pasta do repositório para onde os ficheiros devem ser carregados. É necessário criar a pasta no repositório de destino antes de efectuar o load. Caso contrário é levantado um erro e os dump não é carregado. Uma forma mais simpels de o escrever (e sem criar o ficheiro dump) é:

svnadmin dump d:\repoPathToMove | svnadmin load d:\pathToNewRepo --parent-dir InternalFolde

Um dos problemas que enfrentei nos últimos dias com o Subversion foram os chamados “tree-conflicts”. São essencialmente conflitos que surgem quando é feito a actualização de um nome de ficheiro e o ficheiro é movido, e alguem depois tem no seu “working copy” uma versão ainda anterior a essa operação. Quando tentam efectuar o commit, vão naturalmente encontrar um erro, por tentarem actualizar um ficheiro que não está presente na revisão.

Segundo encontrei, a versão mais recente (1.6) do SubVersion tem melhor suporte para este tipo de erros agora. Mas primeiro, antes de actualizar, justifica (sempre, mesmo que digam que não é preciso) fazer um backup. O backup é um simples “dump” das revisões para um ficheiro e efectuado pelo comando:

>svnadmin dump X:\caminho_do_repositorio X:\Caminho_e_nome_do_ficheiro_do_backup

A extensão do ficheiro gerado pode ser um qualquer, mas recomendo o uso de a data. O commando executa uma descarga completa das bases com as diversas revisões para o ficheiro (binário). O ficheiro tende a crescer muito (nalguns casos centenas de MBs) mas é altamente comprimível.

Infelizmente, como podem ver, é uma execução repositório a repositório. Nada como criar um script para realizar a tarefa (ou um programazito para gerir a lista de repositórios e os dumps!) . Este é um passo que deve ser frequente, para quem tem amor à vida e ao trabalho que realiza… a redundância nestas coisas nunca é demais!

O próximo passo é a actualização do serviço (Windows do servidor de SVN). É conveniente reinicializar o serviço no fim do processo de actualização. Também , dependendo de como instala, pode acabar por ter duas instalações do mesmo serviço (por exemplo eu tinha um server de Subversion inicial a correr, e actualizei com o installer do CollabNet. Fique com dois serviços instalados no servidor).

O último passo da actualização é actualizar os repositórios em si, utilizando o comando upgrade:

>svnadmin upgrade X:\caminho_do_repositorio

Novamente um script ou uma pequena aplicação serão muito úteis para auxiliar este processo para o caso de haver muitos repositórios.

Por fim, actualize tb o cliente (Tortoise, etc.) para que trabalhem bem com o server actualizado. Os working copies no cliente são actualizados automaticamente pelo Tortoise assim que houver o contacto.