Actualizar o servidor de Subversion

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.

PostgreSQL e Linux

Cada vez mais aprecio o PostgreSQL. A base de dados é, efectivamente, muito capaz e poderosa, e felizmente não transporta a barreira das licenças que alguns outros sistemas de base de dados portam. Não é que não os justificam, e empresas que compram licenças desses sistemas reconhecem a sua importância e valor. Mas o PostgreSQL é efectivamente uma base de dados bastante simpático e funcional com um custo reduzido.

Algo que considero muito útil no Postgre é ser multi plataforma. Windows, Linux e MAC.. é escolher, que o PostgreSQL corre. O PgAdminIII, aplicação de gestão da base de dados com GUI também corre em Windows e Linux. Ainda não testei comunicação entre base de dados e servers aplicacionais suportando SOs diferentes, mas penso que é evidente o correcto funcionamento e comunicação.

Hoje estou a instalar um server em Linux, para suportar o JIRA.Tive dificuldades com o Confluence (coisa estranha de má tradução entre IIS e Tomcat dos endereços das páginas), e decidi mover as aplicações de gestão para um server dedicado. O Ubuntu é a minha “flavor” preferida (é todo o conceito…). As aplicações da Atlassian utilizam Tomcat, e tem versões que portam o serviço com elas. Pensei em o server como Tomcat server (o Ubuntu tem essa opção), mas decidi seguir a recomendação do fabricante e deixar as aplicações correr em instâncias dedicadas. O que instalei por defeito foi o clássico LAMP e a base de dados PostgreSQL.

No entanto, o PG n funciona por si só sem uma ligeira configuração. No Windows, é realizado na instalação com o Wizard, mas no Linux é mais simples / imediato com umas linhas de comando. Naturalmente o processo está mais que documento na web, mas nunca é demais reescrever.:

Para começar, duas instruções para instalar o PostgreSQL (caso n tenha sido usado a opção de instalação no processo de instalação do SO):

sudo apt-get install postgresql
sudo apt-get install pgadmin3

O primeiro pode ser ignorado caso a instalação tenha sido efectuada na instalação do SO. A segunda é um GUI de administração muito útil.

Segue então a configuração, sendo necessário inicializar o utilizador base e a password para o mesmo:
sudo -u postgres psql postgres
\password postgres

e introduza a password desejada para o utilizador postgres.

Outras coisas que podem ser feitas:
criar uma bd:> sudo -u postgres createdb [nome da base]
iniciar o serviço:> sudo /etc/init.d/postgresql-8.4 [start | stop | restart]

Finalmente, há mais dois detalhes importantes a resolver. O Postgre é, por defeito, bastante restriivo no acesso, permitindo acesso apenas por conexões vindas da própria máquina. Para aceder remotamente, primeiro deve permitir que os utilizadores da base possam autenticar-se na base na rede (caso queira esta funcionalidade). É necessário acrescentar o seguinte ao ficheiro /etc/postgresql/8.4/main/pg_hba.conf


# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all x.x.x.0 255.255.255.0 md5

onde x.x.x.0 é a definição da rede (p.e. 10.0.0.0 ou 192.168.0.0).

Para que seja possível acesso externo ao servidor de base de dados, e necessário editar /etc/postgresql/8.4/main/postgresql.conf, retirando o comentário à linha #listen_addresses = ‘localhost’
e sustituír ou acrescentar ao ‘localhost’ o ‘*’ para todas as conecções, ou uma gama de IPs para limitar. P.e.:
listen_addresses = ‘*,localhost’

E já vai bem encaminhado 😀