Versionamento Concorrente Completo com Subversion

Transcrição

Implantando um Sistema de Versionamento Concorrente Completo
Com base em: Subversion, Apache2, Trac, TortoiseSVN, etc;
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Este documento é um metaartigo, constituido de uma série de artigos que documentam de forma prática a criação de um ambiente completo de controle e versionamento de projetos de desenvolvimento de software, utilizando Subversion, Trac, TortoiseSVN, entre outros recursos.
Apesar de originalmente projetados para desenvolvimento de software, sistemas de versionamento concorrente pode, e vem sendo utilizado a cada dia para uma série de atividades distintas. É por isso que a FreeBSD Brasil tem disponibilizado a seus clientes este documento, para permitir que possam criar e implantar um sistema desse tipo por si só. Se o desejar, podem solicitar a nosso time de consultoria que implantemos o sistema para você, cliente FreeBSD Brasil. Será um prazer.
O time de Consultoria da FreeBSD Brasil tem ampla experiência na implantação e treinamento in
company para uso do Subversion como sistema de versionamento de projetos com sistema de desenvolvimento paralelo. Temos grandes universidades e institutos de tecnologia como clientes que usam um ambiente de versionamento criado pela FreeBSD Brasil.
A grande vantgaem do ambiente criado é a facilidade de implementar, manter, e atualizar, garantidas pela Coleção de Ports do FreeBSD, além da performance que o ambiente oferece em FreeBSD, já que o Subversion faz uso de BDB (Berkeley Databases) para gerenciar seu repositório, e esse tipo de base de dados tira reconhecido proveito do subsistema de gerenciamento de memória e VM integrada do FreeBSD, além do Subversion, Trac, TortoiseSVN e outros, ser, como FreeBSD, licenceados sob Licença BSD.
Se você é cliente FreeBSD Brasil e deseja ter um ambiente completo de desenvolvimento e versionamento concorrente, entre em contato imediatamente com nosso time de Suporte e Consultoria, através do Porta Corporativo (https://corporativo.freebsdbrasil.com.br), por sua lista de suporte, ou em [email protected].
Atenção: Antes de iniciar os procedimentos aqui documentados, garanta que sua Coleção de Ports esteja atualizada:
portnap fetch
postnap update
http://www.freebsdbrasil.com.br
Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil PARTE I SUBVERSION
Introdução
A cada dia sistemas de versão concorrente vem sendo utilizados para os mais diversos fins. No passado era realidade apenas em grandes ambientes de desenvolvimento paralelo, onde literalmente dezenas de desenvolvedores demandavam acesso simultâneo aos mesmos arquivos, e ter um sistema de versão concorrente era imperativo para garantir adequadamente um ambiente de trabalho concorrente, e principalmente, garantir segurança desses dados, de forma que se um desenvolvedor interferisse negativamente no trabalho de outro, as mudanças em questão pudessem ser facilmente revertidas ao estado anterior.
Hoje a popularização do ambiente de versão concorrentes é maior, e o uso dessas aplicações não tornase mais simples ou acessível, mas sim, mais necessária. O ambiente de versionamento hoje é parecido com o que era, em termos operacionais, há uma década atrás. Porém os conceitos de desenvolvimento evoluíram, e hoje até mesmo projetos com um ou dois desenvolvedores são mantidos em base de versão concorrente, pois garante segurança e acompanhamento histórico da evolução de cada projeto.
Mais que isso, não apenas projetos de desenvolvimento de software usam sistemas de versionamento hoje. Desde desenvolvimento de websites até documentos de editoração eletrônica, como Corel Draw ou Photoshop, incluindo documentos de texto formado Word ou OpenOffice, são mantidos em sistemas de versão concorrente. A possibilidade de backup automatizado e fácil, garantindo aumento de segurança, e reversão de modificações, são o principal motivador para a adoção desse tipo de ambiente
de
desenvolvimento.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Hoje existem dezenas de opções de sistemas de versionamento de projetos, esses sistemas são conhecidos com SCM ou apenas VCS (Version Control System). Alguns sistemas VCS comerciais, mais conhecidos são:
•
Clear Case
•
Microsoft Team Foundation
•
Perforce
E alguns sistemas de controle de versão livres, mais conhecidos são:
•
CVS
•
Subversion
•
GIT
Outros
sistemas
•
Visual Source Safe
•
PVCS
•
SVK
•
HG
•
BZR
menos
conhecidos:
Entre os sistemas proprietários, o Clear Case é o mais conhecido, porém de forma geral oferece uma boa relação entre custo e recursos, apesar de não ter performance como outros concorrentes, e portanto não indicado para ambientes de desenvolvimento muito grandes (e muito grandes nos referimos a centenas de modificações por dia, literalmente por centenas de desenvolvedores simultânea/paralelamente).
Entre os desenvolvedores que trabalham com diversos sistemas de versionamento, http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil a opção comercial mais adotada, e considerada a melhor no quesito funcionalidades, facilidade de uso e performance é o Perforce. Porém, o Perforce é conhecido por ser um sistema de alto custo em suas versões mais completas.
O sistema aberto mais conhecido é o CVS, exatamente por existir há mais tempo, e ser a primeira implementação livre com um número de recursos que o tornasse viável a ser utilizado em todo tipo de ambiente, de qualquer porte, de projetos pequenos a gigantescos. O CVS é a opção de escolha mais comum, entre livres e comerciais. Ao menos por enquanto.
O Projeto FreeBSD é um dos mais compexos, dinâmicos e organizados projetos de desenvolvimento de Software no mundo. É o único projeto que já teve tese de pós
graduação defendida, pois seu modelo exclusivo mostrase diferente e muito eficiente.
No Projeto FreeBSD, existe um time central, chamado Core Team, composto de 7 a 9 desenvolvedores, que coordenam as políticas e objetivos do Projeto. Porém, o desenvolvimento ativo acontece paralelamente em um ambiente de versionamento concorrente em três árvores independentes, são elas:
1.
A árvore do src (o FreeBSD de fato);
2.
A árvore de Ports;
3.
A
árvore
de
Documentação;
E, diferente de outros projetos livres ou proprietários, o acesso efetivo a essas árvores de desenvolvimento não é coordenado ou supervisionado por um, ou um time de desenvolvedores chefe. Cada um dos cerca de 400 desenvolvedores FreeBSD tem liberdade, e são responsáveis por suas modificações, e podem realizar essas mudanças nos ramos de desenvolvimento, segurança ou produção do sistema, sem nenhuma supervisão, sendo os único responsáveis por suas mudanças.
Esse é um modelo regido por normas e regras bem estabelecidas, e http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil principalmente, apesar de a primeira vista parecer caótico e anárquico, é muito bem projetado, rígido em procedimentos, e principalmente funcional, oferece liberdade para evolução distribuída do Projeto, sem depender de decisões centralizadas.
Exatamente por isso o Projeto FreeBSD é um dos maiores exemplos de desenvolvimento paralelo de software no mundo hoje. Todos os outros projetos, como Linux, NetBSD, OpenBSD, ou até mesmo de desenvolvimento de software proprietário seguem os padrões convencionais, tendo um líder, ou um supervisor responsável pela auditoria e controle de tudo que acontece, das atividades de cada desenvolvedor, ou tem
um
time
responsável
por
essa
tarefa.
Exatamente por isso o Projeto FreeBSD é conhecido como o ambiente que mais põe a prova sistemas de desenvolvimento e versionamento concorrente. O CVS há anos tem sido o principal sistema de versionamento utilizado, e tem atendido o Projeto muito bem. Contudo, não é o único. Oficialmente os sistemas utilizados no Projeto são CVS e Perforce. Sim, o comercial e caríssimo Perforce.
O Projeto FreeBSD não adquire licenças do Perforce, tão pouco usa versões ilegais. O Perforce é doado ao Projeto FreeBSD, pois vários desenvolvedores FreeBSD são financiados pela Perforce, e principalmente também porque o Perforce gosta de ter um dos maiores projetos de Software do mundo, com características tão peculiares ao ponto de existir tese de pós graduação estudandoo, que usa o Projeto FreeBSD como referência, pois de forma geral poucos projetos tem esse nível de complexidade.
Inúmeros commiters FreeBSD preferem trabalhar no Perforce do que no CVS. Quase metade. As desvantagens do CVS são o fraco suporte a versionamento binário, ausência de alguns recursos adotados recentemente em outros sistemas, e também menor performance geral que outras soluções, como o próprio Perforce.
Não oficialmente, árvores alternativas são usadas por commiters com outros sistemas, como GIT. Porém, não são iniciativas oficais, e de forma geral são usadas por http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil poucos
desenvolvedores.
Contudo, o CVS tem sua liderança ameaçada a cada dia por um novo sistema: Subversion
(ou
apenas
SVN).
O Subversion apresenta, entre todas as opções, uma das melhores implementações no quesito performance, concorrendo ladoalado com Perforce. Apresenta o melhor suporte a versionamento de arquivos binários do mundo, pois utiliza o BSDiff e BSDPatch criados por Colin Percival, commiter FreeBSD. Tem ainda a vantagem de ser licença BSD, trabalhar com um conceito mais simples de árvore genealógica de versões, oferecer recursos modernos, e ter o desenvolvimento muito mais ativo que qualquer outro
sistema
de
versionamento
livre.
O Projeto FreeBSD planeja migrar para os próximos 18 meses sua estrutura primária de CVS para SVN. Hoje o SVN já é utilizado, experimentalmente.
Nestes endereços:
http://wiki.freebsd.org/VersionControl
http://wiki.freebsd.org/SVN_Repo_Layout
http://wiki.freebsd.org/SVN_Merging
É possível acompanhar o minucioso trabalho de avaliação das alternativas ao CVS, suas limitações, suas vantagens, e seus recursos. E também é possível observar o maior trabalho, realizado por
Nik Clayton, acerca da migração para SVN.
Exatamente pelo destaque maior que SVN tem hoje em dia, qualquer nova implantação de sistemas de versionamento utiliza SVN. CVS é sistema legado, e todos os projetos tendem a migrar de CVS para SVN. Alguns dos mais famosos projetos que já realizaram
essa
migração
são:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil •
Apache Apache Foundation
•
SpamAssassin Apache Foundation
•
KDE KDE Project
•
Mono
•
Samba
•
Conectiva/Mandriva
•
Outros...
Um comparativo entre Subversion e outros sistemas de versão concorrente, pode ser encontrado aqui:
http://www.szabgab.com/subversion_vs_xyz.html
Objetivo Deste Artigo
Ao longo deste documento configuraremos o mais completo ambiente de trabalho utilizando Subversion, que inclui:
•
Subversion;
•
Apache2 com suporte a DB4.2
•
Módulo mod_dav para Apache2
•
Módulo mod_dav_svn para Apache2
•
Módulo mod_authz_svn para Apache2
Com esse ambiente, combinaremos duas das mais poderosas ferramentas do mundo
de
Software
Livre,
o
Apache
e
o
Subversion.
Subversion suporta transporte nativo, protocolo svn://, local, protocolo file:// e remoto com ssh:// e também com Apache, utilizando http:// ou https://. O Subversion tem seu próprio sistema de controle de usuários, mas permite http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil integração de seu ambiente de autenticação com sistema nativo (usuários do sistema local), bem como através dos sistemas de autenticação Apache.
A integração com Apache é a mais indicada, e a que utilizaremos. Ao final da primeira etapa nós teremos:
•
Repositório SVN totalmente funcional;
•
Controle de Acesso por Usuários e Grupos em Cada Repositório, sendo feito pelo arquivo /usr/local/etc/svn_authz.conf;
•
Definição de usuários e senhas em /usr/local/etc/svnpasswd
•
Estrutura de repositório disponível em /usr/home/svn
E faremos nossos primeiros teste criando um repositório, fazendo nosso primeiro checkout, adicionando o primeiro arquivo e por último, realizando nosso primeiro commit.
Instalação do Apache2
A primeira etapa é garantir que o Apache 2.0 esteja instalado em seu ambiente, e com suporte a DB4, no mínimo a versão DB 4.2, para isso, através da Coleção de Ports do FreeBSD basta apenas:
cd /usr/ports/www/apache20/
make WITH_BERKELEYDB=db42 install clean
Instalando o Subversion
Agora é necessário instalar o Subversion com suporte a APR do Apache2, com suporte a MOD_DAV_SVN, suporte a MOD_SVN_AUTHZ e com suporte a ASVN. De forma geral isso seria uma tarefa um tanto quanto árdua e manual, em outros sistemas. Mas http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil não através da Coleção de Ports do FreeBSD, onde esse procedimento se resume a:
cd /usr/ports/devel/subversion/
make WITH_MOD_DAV_SVN=yes WITH_APACHE2_APR=yes \
WITH_SVNSERVE_WRAPPER=yes WITH_ASVN=yes install clean
Se houver qualquer conflito ou problema na compilação do /usr/ports/www/neon (que é uma dependência a esse nosso ambiente), deinstale e reinstaleo, combinando
pkg_delete -f neon-\*
cd /usr/ports/www/neon/
make install clean
E retorne ao procedimento de instalação do Subversion.
Configuração do Apache
Nosso ambiente almejará a mais complexa abordagem, onde existirão diversos repositórios, cada qual com sua própria política de acesso, onde a princípio todos terão acesso de leitura (acesso anônimo) mas apenas usuários autenticados poderão fazer modificações em cada repositório. A política de acesso poderá ser redefinida a qualquer momento através do arquivo de controle authz do Subversion, que aprenderemos a seguir.
Todas as operações feitas através do sistema WEB_DAV, (sistema de Directories sobre protocolo HTTP) em especial do MOD_DAV_SVN fazem verificações de segurança que dependem do nome da estação local ser plenamente conhecida pelo Apache. Então assumiremos que no seu ambiente, já existe uma entrada DNS adequadamente configurada, que aponte para o servidor onde está o Subversion, e essa entrada tenha o http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil nome:
svn.dominio.com.br
Qualquer nome é válido, e de fato seu servidor provavelmente já terá um nome de DNS adequadamente configurado. Pode utilizar esse nome, não há necessidade, obviamente, de ter a expressão “svn” no endereço do host.
Garanta que seu FreeBSD esteja com hostname devidamente configurado (hostname=”svn.dominio.com.br”, no /etc/rc.conf), adicione as entradas apropriadas no /etc/hosts:
IP
svn.dominio.com.br
svn
127.0.0.1
localhost.localdomain
localhost
Edite o arquivo de configuração do Apache,
vi /usr/local/etc/apache2/httpd.conf
Procure pela entrada ServerName e configurea apropriadamente:
ServerName svn.dominio.com.br
Procure pelo bloco de entradas LoadModule, e observe que o Ports já adicionou as seguintes entradas no final desse bloco:
LoadModule dav_module
libexec/apache2/mod_dav.so
LoadModule dav_svn_module
libexec/apache2/mod_dav_svn.so
LoadModule authz_svn_module
libexec/apache2/mod_authz_svn.so
Dessa forma carregamos os módulos DSO do Apache que nos dá suporte à DAV, http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil DAV_SVN e AUTHZ_SVN, o primeiro é suporte geral a WEB_DAV, o segundo é suporte ao SVN através do protocolo http:// encapsulado em uma implementação padrão WEB_DAV, e o último garante suporte aos recursos de autenticação de usuários estilo SVN, para acesso aos repositórios.
Se o ports não adicionar essas entradas, desconfie que o procedimento de instalação do Subversion não foi completado adequadamente ou que algo deu errado, revise a saída do processo e reinicie a instalação do subversion. Se tudo foi completado com sucesso é provável que seu httpd.conf já tenha sido modificado drásticamente, e o sistema de ports não identificou onde adicionar essas entradas, então garanta que esses módulos existem em ${PREFIX}/libexec/apache2/
Onde ${PREFIX} por padrão equivale a /usr/local:
ls /usr/local/libexec/apache2/*svn*.so
E adicione as entradas apropriadamente em seu httpd.conf (normalmente desnecessário, pois raramente o ports não conseguirá adicionalas para você).
Atenção:
Esse é o momento apropriado para você pensar em modos de acesso, permissões, autoridade e direitos. Considere que o Apache terá que ter acesso de escrita na estrutura de respositório do Subversion. Então você pode garantir por exemplo que o grupo do Apache (www) tenha direito de escrita em todos seus repositórios Subversion, ou se preferir criar um grupo adicional, que terá privilégios de escrita nos seus repositórios, e colocar o usuário do Apache (www) nesse grupo, ou ainda substituir o grupo com que o Apache executará, através da directiva:
Group <grupo>
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Atenção:
Esse é o momento apropriado para você pensar em modos de acesso, permissões, autoridade e direitos. Considere que o Apache terá que ter acesso de escrita na estrutura de respositório do Subversion. Então você pode garantir por exemplo que o grupo do Apache (www) tenha direito de escrita em todos seus repositórios Subversion, ou se preferir criar um grupo adicional, que terá privilégios de escrita nos seus repositórios, e colocar o usuário do Apache (www) nesse grupo, ou ainda substituir o grupo com que o Apache executará, através da directiva:
Se tiver dúvidas sobre a melhor abordagem, ou seu ambiente não estiver dedicado a outras funções complementares, continue seguindo este documento e use a abordagem aqui indicada. Uma outra opção mais elaborada é utilizar ACLs. Porém, desnecessária.
Nossa estratégia de permissões será a mais segura o possível, dando apenas os direitos de acesso que o Apache precisa, apenas nos diretórios apropriados, e nada além disso, inclusive, sem atribuir privilégio adicional algum a nenhum arquivo ou tornar o grupo www proprietário dos arquivos do Subversion. Adicione então um grupo chamado 'svn'. Esse grupo será proprietário de nosso ambiente de repositório, e terá privilégios de escrita exclusivamente onde necessário, nenhum local a mais:
pw groupadd svn
Agora garante que o usuário www (que roda o Apache) seja parte desse grupo, sem modificar a grupo primário do usuário, tão pouco fazendo o Apache rodar com
Group svn
Basta garantir no sistema que o usuário Apache seja parte do grupo svn complementarmente (não grupo primário). Para isso, seguindo o clássico e bom estilo http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil BSD, basta usar o pw(1) e adicionar o usuário www como membro do grupo svn:
# pw moduser www -G svn
Ou se preferir edite o /etc/group e na entrada do grupo svn, na última coluna, adicione o usuário www como membro. Se houver (normalmente não haverá, exceto em abiente complexo de desenvolvimento) mais de um usuário nesse grupo, a lista deve ser separada por virgula. A entrada do grupo svn no arquivo /etc/group ficará similar a:
svn:*:1015:www
Ou eventualmente, se houver mais de um usuário nesse grupo:
svn:*:1015:eksffa,www
Agora adicione ao httpd.conf (/usr/local/etc/apache2/httpd.conf) uma entrada do tipo Location, dentro do bloco global, junto ou em um container VirtualHost se desejar, indicando como o Apache deve se comportar quando o endereço desejado para acesso aos repositórios for utilizado. Esse endereço será o
http://svn.dominio.com.br/svn/
E a entrada deve ser a seguinte:
<Location /svn>
DAV svn
SVNParentPath /usr/home/svn
AuthzSVNAccessFile /usr/local/etc/svn_authz.conf
Satisfy Any
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Require valid-user
AuthType Basic
AuthName "Repositorios SVN FreeBSD Brasil LTDA"
AuthUserFile /usr/local/etc/svnpasswd
</Location>
Cada uma dessas entradas tem valores a nossa escolha:
DAV svn – essa entrada indica ao Apache para processar esse endereço (Location) como Web DAV, em especial o módulo DAV_SVN, que fará o interfaceamento entre o protocolo http e o protocolo utilizado pelo Subversion;
SVNParentPath – essa entrada aponta a estrutura base onde estarão todos os nossos respositórios Subversion; como nosso ambiente contempla múltiplos repositórios, apontamos para a base; se seu intúito for apenas um respositório pode apontar diretamente para a estrutura do próprio;
AuthzSVNAccessFile – aponta para o arquivo de configuração onde as políticas de acesso a cada repositório estarão disponívies; por padrão esse arquivo não existe, então você pode apontálo para onde desejar, já que teremos que criálo; o caminho escolhido nesse documento é o mais apropriado pois fica no ${PREFIX} de aplicações de terceiros, e também identifica adequadamente o conteúdo desse arquivo de configuração;
As outras opções: não são instruções intrísecas ao Subversion, mas sim tradicionais do Apache, que controlam regras de autenticação para acessar esse Location; A estratégia aqui é a seguinte: primeiro, tentamos acessar uma determinada estrutura sem autenticação (Satisfy Any). Todas que conseguirmos, navegaremos normalmente. Em determinado momento, se o SVN_DAV identificar uma estrutura de http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil respositório ou um repositório que tenha política de acesso por usuário (configurado no arquivo svn_authz.conf), e este usuário não estiver logado, a princípio ele tentará gerar um erro de acesso no Apache, porém, o Apache cairá no fallback para a entrada Require valid-user. Isso ativará o AuthType, configurado como Basic, e o Apache solicitará usuário e senha, que serão verificados no arquivo indicado pelo AuthUserFile. Se a autenticação for concluída com sucesso o DAV_SVN terá a informação de que usuário está autenticado, e se este usuário estiver com acesso autorizado no arquivo svn_authz.conf, o acesso é permitido, senão o Apache retornará uma mensagem de código 403 (Forbidden). AuthName é opcional e serve apenas para identificar acesso ao quê, requer autenticação.
Portanto ainda temos que criar o arquivo apontado por AuthUserFile e também AuthzSVNAccessFile, que não existem.
Agora garanta que o acesso a estrutura de respositórios SVN é permitido por qualquer origem:
<Directory /usr/home/svn>
AllowOverride None
Order Deny,Allow
Allow from all
</Directory>
Note que, apesar de incomum para essa nossa abordagem, se apenas um endereço ou apenas uma rede puder acessar essa estrutura, você pode trabalhar melhor esse recurso do Apache, por exemplo, para permitir que apenas os endereços 10.69.4.5 e 10.20.10.5 acessem a estrutura:
<Directory /usr/home/svn>
AllowOverride None
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Order Deny,Allow
Allow from
10.69.4.5 10.20.10.5
Deny from all
</Directory>
No caso acima ainda que autenticado ou com todas permissões no ambiente, apenas os endereços IP mencionados poderão acessar nossos repositórios. Use com cautela.
Por último, se você for adepto de obscuridade de informações, não vai querer que ninguém saiba através de cabeçalhos http ou na assinatura automática de páginas geradas pelo Apache, que você tem suporte a esses módulos DAV, então se desejar modifique a entrada ServerTokens para Prod:
ServerTokens
Prod
Criando Um Repositório
Nossa estrutura de repositórios ainda não existe, então vamos criála, e dar as permissões adequadas, inclusive propriedade ao grupo que criamos (svn):
mkdir /usr/home/svn
chgrp svn /usr/home/svn
E vamos criar o repositório propriamente dito. Nesse exemplo criaremos um repositório chamado projeto01. Para isso, usaremos a aplicação svnadmin com o argumento create:
svnadmin create /usr/home/svn/projeto01
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Agora vem a questão sobre privilégios. Quando se conhece como o Subversion trabalha de fato, é fácil identificar onde o privilégio de escrita é necessário. A documentação oficial do Subversion é exemplarmente completa, e observandoa, identificamos que o acesso de escrita é necessário apenas nos diretórios
db/
dav/
Em cada repositório. Portanto na nossa abordagem, será necessário privilégio de escrita em:
/usr/home/svn/<repositorio>/db
/usr/home/svn/<repositorio>/dav
Onde <repositorio> é cada respositório que criarmos. Portanto como acapabos de criar o repositório de versões concorrentes projeto01, garanta a propriedade desses diretórios ao grupo svn e os privilégios adequados:
chgrp -R svn /usr/home/svn/projeto01/db /usr/home/svn/projeto01/dav
chmod -R g+rwx /usr/home/svn/projeto01/db /usr/home/svn/projeto01/dav
Agora através de um navegador Web acesse:
http://svn.dominio.com.br/svn/projeto01/
Note que o Apache pedirá autenticação, mesmo para leitura! Isso porque não avisamos em lugar algum que qualquer usuário tem acesso de leitura a este repositório. De fato, não informamos que qualquer usuário tem acesso a qualquer coisa, então ainda que conseguíssemos nos autenticar (o que é impossível, já que nenhum usuário existe ainda), ainda assim não teríamos permissão alguma, pois o usuário autenticado não é permitido a fazer nada pelo sistema de autenticação do Subversion por DAV_SVN.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Adicionando Usuários
No arquivo indicado por AuthUserFile, em nosso caso, /usr/local/etc/svnpasswd, criaremos os usuários e definiremos as senhas, no melhor estilo Apache.
Para isso, crie o arquivo e o primeiro usuário com o comando htpasswd que foi instalado junto com o Apache, com os argumentos c e m. Criaremos o usuário 'patrick' no exmeplo a seguir:
# htpasswd -c -m /usr/local/etc/svnpasswd patrick
New password:
Re-type new password:
Adding password for user patrick
Como observado o sistema pedirá a senha do usuário, e depois solicitará confirmação dessa senha para só depois adicionálo ao arquivo indicado. Se desejar (não indicado, por motivos de segurança), é possível passar a senha na linha de comando, evitando que esta seja solicitada interativamente:
htpasswd -c -m /usr/local/etc/svnpasswd patrick <senha>
O argumento -c cria o arquivo, e portanto deve ser usada exclusivamente a primeira vez que um usuário for adicionado, e nenhuma outra. Senão o arquivo será recriado. O argumento -m faz o sistema usar senha MD5, muito mais seguro que as combinações DES que o Apache usa por padrão. A partir do segundo usuário, adicioneos sem o argumento c portanto:
htpasswd -m /usr/local/etc/svnpasswd usuario2
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil As entradas nesse arquivo nesse momento deverão estar similares a seguinte:
# cat /usr/local/etc/svnpasswd
patrick:$apr1$T.esb...$kzs8//8GG0oGj.a4XVj7U.
usuario2:$apr1$PXF5c...$ZbUhwEiQjcInYBs9Qi8690
Ótimo, agora acesse novamente
Observe que mais uma vez será pedida autenticação, autentiquese com o usuário que acaba de ser criado. Você notará que o Apache permitirá a autenticação, com sucesso, mas o acesso ao endereço acima ainda estará proibida, e o Apache retornará um erro 403 (Forbidden).
Ótimo. Afinal não configuramos ainda o que cada usuário pode fazer, portanto, não podem fazer nada por padrão.
Configurando Políticas de Acesso (Authz) DAV_SVN (AuthzSVNAccessFile)
O arquivo de configuração indicado pela directiva AuthzSVNAccessFile segue o mesmo formato dos arquivos authz nativos do Subversion, bem como do arquivo svnserve.conf, com exceção que dispensaremos o arquivo passwd, pois usuários e senhas controlamos pelo sistema de autenticação do Apache.
Felizmente esse arquivo é extremamente simples e intuitivo. Ele é composto de blocos de configuração, e estes blocos podem ser dispostos em qualquer local do arquivo, os blocos são dois, o primeiro, opcional, é o bloco de grupos, que permite que http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil definamos grupos de usuários e os usuários parte desse grupo. Devemos definir um grupo por linha após a definicão do bloco [groups], por exemplo:
[groups]
grupo1 = usuario1, usuario2, usuario3
Os próximos blocos indicam as políticas de acesso que definiremos para cada repositório ou subsessão de um repositório. Para isso temos dois tipos de privilégios:
r = privilégio de leitura
w = privilégio de escrita
Se quisermos definir uma política válida para todos os repositórios, basta identificarmos através do bloco raiz. Os blocos que identificam políticas por repositório tem o seguinte formato:
[<repositorio>:<path>]
Por exemplo:
[repositorio1:/] Indicará as permissões para o repositorio1 inteiro;
[repositorio1:/cliente02/] Indicará as permissões apenas para a estrutura /cliente02 dentro do repositorio1;
[/] Indicará as permissões para todos os repositórios; esse tipo de entrada não tem precedência alguma, e qualquer definição seletiva por repositórios sobrepõe essas definições;
O formato de regras de acesso para cada repositório segue o padrão:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil [<repositorio>:<path>]
<usuario> = <privilegio>
<usuario> = <privilegio>
Podem haver inúmeras linhas de permissões por bloco; os recursos <privilegio> já conhecemos, podem ser r (leitura) ou w (escrita), e <usuario> pode ser:
* todos os usuários;
@grupo – um grupo de usuários;
usuário – apenas o usuário;
É amplamente indicado que definamos grupos de usuários sempre que possível, pois facilita o controle de acesso a cada repositório.
Configurando nosso arquivo de política de acesso
Agora que já conhecemos o formato do arquivo indicado por AuthzSVNAccessFile, podemos configurar nossa política de acesso. Edite então o arquivo /usr/local/etc/svn_authz.conf:
vi /usr/local/etc/svn_authz.conf
E nele vamos configurar nosso bloco de grupos inicialmente, criando um grupo composto de nossos usuários, e outro grupo de exemplo, composto de um de nossos usuários e um usuário ainda inexistente:
#
# Definicao de grupos
#
[groups]
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil grupo1 = patrick, usuario2
grupo2 = usuario2, cliente3
Agora podemos começar a configurar a política de acesso para cada repositório. É indicado inicialmente ter uma política para todos os repositórios, criaremos uma política portanto que permite que qualquer usuário, mesmo não autenticado, tenha privilégio de leitura a todos nossos repositórios. Lembrando que essa é uma política de exemplo e propícia a sistemas abertos, onde qualquer um pode livremente acessar todos os projetos, mas apenas desenvolvedores autorizados podem fazer modificações nos repositórios. Se seu ambiente for totalmente privado, essa política livre de leitura não se adequará a você, provavelmente.
Complemente então o /usr/local/etc/svn_authz.conf com a seguinte entrada:
#
#
[groups]
grupo1 = patrick, usuario2
#
# Politica de Acesso por Repositorios
#
# Todos os repositorios (politica padrao)
[/]
* = r
Agora aponte seu navegador web para a URL svn do projeto:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil E você perceberá que pela primeira vez, foi possível fazer acesso a nosso repositório projeto01, e o navegador não pedirá autenticação para permitir o acesso de leitura a esse e qualquer outro repositório. Isso porque você informou que todos os usuários (*) tem acesso de leitura (r) a todos os repositórios ([/]);
É hora de definir uma política a nosso respositório. Nesse exemplo informaremos que o grupo1 poderá ter acesso pleno (leitura e escrita):
#
#
[groups]
#
#
[/]
* = r
# Repositorio projeto01
[projeto01:/]
@grupo1 = rw
Se não desejar que globalmente, usuários anônimos (não autenticados) possam ter acesso de leitura, remova a configuração de política padrão ([/]) e defina a política de acesso anônimo (*) para cada repositório, individualmente. Lembrando que podem haver quantas definições você quiser, uma por linha. Segue um exemplo de definição http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil mais abrangente:
#
#
[groups]
#
#
[/]
* = r
[projeto01:/]
@grupo1 = rw
@grupo2 = r
[projeto02:/]
* = r
@grupo1 = rw
[projeto02:/publico]
* = rw
[projeto02:/ramo2]
usuario2 = rw
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil @grupo2 = r
Introdução ao svn em linha de comando
Para testarmos nosso ambiente, devemos primeiro ter algum conhecimento, ao menos básico, do ambiente de linha de comando do svn, do ponto de vista de um usuário frequente do sistema de versionamento Subversion;
A lista completa de comandos e argumentos ao aplicativo svn pode ser observada, inclusive documentada, em:
http://svnbook.redbean.com/en/1.1/ch09.html
Ou em português (em processo de tradução) em
http://svnbook.redbean.com/nightly/pt_BR/svn.ref.html
Ambiente de Trabalho
A primeira coisa a fazer é criarmos nosso ambiente de trabalho local. O conceito de trabalho em um sistema de versionamento concorrente é simples: você deve ter uma versão local do repositório em que irá trabalhar, ou seja, precisa ter o repositório localmente iniciado (comando checkout), e cada modificação local não é efetivada no repositório até que você ordene (comando commit). Cada arquivo criado localmente não pode ser efetivado antes de ser adicionado (comando add).
Se você está acostumado com outros ambientes como CVS ficará surpreso com a simplicidade de abordagem no Subversion, sem a necessidade de definir milhares de variáveis de ambiente para constituir seu ambiente de trabalho. Se não estiver, terá uma ótima experiência inicial com Subversion.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Crie uma estrutura de diretório que chamará de svn_root; lembrando que se você estiver desempenhando as atividades de cliente em uma estação distinta (normalmente estará) precisa instalar o Subversion, pode fazer isso com as mesmas instruções anteriores, mas você não depende do Apache ou recursos adicionais, basta apenas um make install clean:
cd /usr/ports/devel/subversion
make install clean
rehash
crie seu ambiente de trabalho:
mkdir ~/svn_root
Entre nesse diretório e faça o checkout do repositório:
# svn checkout http://svn.dominio.com.br/svn/projeto01
Checked out revision 0.
O comando 'svn co' é sinônimo de 'svn checkout', podese usar portanto qualquer um deles. Alias existem sinônimos simplificados para cada comando. Não usaremos os sinônimos simplificados para melhor entendimento dos comandos.
Observe através da mensagem Checked out revsion 0 que você completou o checkout com sucesso, e que a árvore atual está na revisão (versão) 0. Dentro de ~/svn_root/ liste o conteúdo:
% ls
projeto01/
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Observe o conteúdo dentro dessa estrutura:
% ls -1 projeto01/
.svn/
Portanto apenas o diretório ~/svn_root/projeto01/.svn/ foi criado, e dentro dele estão os arquivos de controle do svn para a cópia local de seu repositório. São arquivos que você precisará modificar raramente – de fato é provável que nunca precise modificar nada ai dentro, já que cada atividade que se faça nesse diretório pode ser feita com comandos mais apropriados). Observe o conteúdo:
% ls -1 projeto01/.svn/
all-wcprops
entries
format
prop-base/
props/
text-base/
tmp/
Portanto não há qualquer arquivo no repositório, que seja parte de seu projeto. Os únicos arquivos são de controle, do próprio Subversion. É hora de aprender um pouco sobre o ambiente de versionamento.
Entre em ~/svn_root/projeto01/ e crie seu primeiro arquivo:
% cd projeto01/
% echo "Meu primeiro arquivo" > LEIAME.txt
% echo "Este e o repositorio do projeto01, leia os termos de
licenca." >> LEIAME.txt
% ls
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil .svn/
LEIAME.txt
Perfeito, porém, o arquivo LEIAME.txt existe apenas na sua estação, e não no repositório. Para adicionar ao repositório use o comando svn add:
% svn add LEIAME.txt
A
LEIAME.txt
Na prática, o comando svn add apenas adiciona o arquivo na lista local de arquivos que fazem parte desse repositório (o repositório de versionamento concorrente onde você está trabalhando), mas para de fato adicionar o arquivo no repositório você deve efetivar a alteração com o comando svn commit. É preciso adicionar uma mensagem de log, e esta deve ser o mais rica o possível em detalhes, pois é a principal documentação de cada modificação que você faça no repositório. Você pode adicionar (svn add), efetivar (svn commit) e fazer qualquer operação com arquivos únicos ou diretórios inteiros. Se não passar a mensagem com o argumento m o sistema abrirá seu ${EDITOR} de textos padrão pedindo para que você escreva a mensagem de log para o commit. É interessante passar os logs na linha de comando, quando as mensagens forem pequenas (commit messages de poucas linhas)
Vamos efetivar então nossa mudança:
% svn -m "Este e o meu primeiro commit, estou iniciando o
repositorio
projeto01
e
importando
os
dados
iniciais."
commit
LEIAME.txt
Nesse momento, se seu repositório não permite escrita anônima, repositório exigirá autenticação:
% svn -m "Este e o meu primeiro commit, estou iniciando o repositorio projeto01 e
importando os dados iniciais." commit LEIAME.txt
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Sending
LEIAME.txt
Authentication realm: <http://svn.dominio.com.br>
Repositorios SVN FreeBSD Brasil
LTDA
Password for 'eksffa':
Authentication realm: <http://svn.dominio.com.br>
Repositorios SVN FreeBSD Brasil
LTDA
Username: patrick
Password for 'patrick':
Transmitting file data .
Committed revision 1.
%
Ou seja, o sistema a princípio tentará se autenticar com o usuário Unix local (${USERNAME}), se não for válido, permitirá que você defina o nome de usuário e se este for válido, solicitará a senha. Se a senha estiver correta e o usuário em questão tiver acesso de escrita ou for membro de um grupo com acesso de escrita, como é o caso do usuário 'patrick' usado no exemplo acima, o arquivo será efetivado (submetido) e você notará a mensagem final dizendo Commited revsion X onde X será o nome da revisão (versão) da árvore no seu repositório de trabalho.
Apenas a primeira vez será preciso se autenticar. O sistema se lembra depois, por 300 segundos, que você já está autenticado. É possível evitar que o sistema tente um nome de usuário sozinho ou que te pergunte, passando na linha de comando o usuário. Por exemplo, façamos uma segunda modificação:
% echo "Segunda modificacao" >> LEIAME.txt
% svn --username patrick -m "commit de teste" commit LEIAME.txt
Password:
Sending
LEIAME.txt
Transmitting file data .
Committed revision 2.
A partir desse momento, durante os próximos 300 segundos não será mais necessário passar o username nem digitar sua senha novamente.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Obtendo informações do repositório remoto
A partir desse momento poderemos a qualquer momento solicitar informações do repositório SVN remoto. Por exemplo, para listar os arquivos disponíveis no repositório, podemos usar o comando svn list:
% svn list http://svn.dominio.com.br/svn/projeto01
LEIAME.txt
Para obter um resumo das informações do repositório, podemos usar svn info:
% svn info http://svn.dominio.com.br/svn/projeto01
Path: projeto01
URL: http://svn.dominio.com.br/svn/projeto01
Repository Root: http://svn.dominio.com.br/svn/projeto01
Repository UUID: cd77f28f-8d2e-0410-9732-c18be92bd7fd
Revision: 3
Node Kind: directory
Last Changed Author: patrick
Last Changed Rev: 3
Last Changed Date: 2007-04-21 21:16:11 -0300 (Sat, 21 Apr 2007)
Inclusive para obter informações sobre cada arquivo:
% svn info http://svn.dominio.com.br/svn/projeto01/LEIAME.txt
Path: LEIAME.txt
Name: LEIAME.txt
URL: http://svn.dominio.com.br/svn/projeto01/LEIAME.txt
Repository Root: http://svn.dominio.com.br/svn/projeto01
Repository UUID: cd77f28f-8d2e-0410-9732-c18be92bd7fd
Revision: 3
Node Kind: file
Last Changed Author: patrick
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Last Changed Rev: 3
Last Changed Date: 2007-04-21 21:16:11 -0300 (Sat, 21 Apr 2007)
Nesse caso, o arquivo LEIAME.txt encontrase em sua terceira revisão, que de fato é a revisão da árvore. Temos a data de última modificação, o nome do usuário que fez a última alteração, a URL e caminho do arquivo no repositório.
Com o comando svn diff podemos tirar um diff remoto entre qualquer arquivo, como ele era em cada revisão, arbitráriamente. Por exemplo, pelo svn info eu pude saber que a árvore nesse repositório encontrase na revisão 3. Quero saber qual a diferença desse arquivo como ele era na revisão 1 da árvore comparado com a revisão 2, portanto a diferença entre duas revisões passadas. Para isso o svn diff com o argumento r permitenos escolher revisões arbitráriamente:
% svn diff -r 1:2 http://svn.dominio.com.br/svn/projeto01/LEIAME.txt
Index: LEIAME.txt
===================================================================
--- LEIAME.txt
(revision 1)
+++ LEIAME.txt
(revision 2)
@@ -1,2 +1,3 @@
Meu primeiro arquivo
Este e o repositorio do projeto01, leia os termos de licenca.
+
Portanto a única diferença é uma linha em branco a mais. Vejamos da revisão 1 com a 3:
% svn diff -r 1:3 http://svn.dominio.com.br/svn/projeto01/LEIAME.txt
Index: LEIAME.txt
===================================================================
--- LEIAME.txt
(revision 1)
+++ LEIAME.txt
(revision 3)
@@ -1,2 +1,4 @@
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Meu primeiro arquivo
Este e o repositorio do projeto01, leia os termos de licenca.
+
+Segunda modificacao
Portanto a diferença é uma linha em branco a mais e uma linha contendo Segunda modificacao.
Revisando mensagens de log de commit
Com svn log é possível analisar todas as mensagens de log de um arquivo, diretório, ou repositório inteiro remoto. Se você não informar a revisão desejada, obterá as informações de log de todas as revisões. Senão, com o argumento r pode informar a revisão que desejar obter a mensagem de log. Por exemplo, quero obter a mensagem de log da revisão 3 do arquivo em questão:
% svn log -r 3 http://svn.dominio.com.br/svn/projeto01/LEIAME.txt
-----------------------------------------------------------------------r3 | patrick | 2007-04-21 21:16:11 -0300 (Sat, 21 Apr 2007) | 1 line
commit de teste
------------------------------------------------------------------------
Portanto commit de teste foi o que o usuário patrick logou, em uma modificação de uma linha (1 line) na revisão 3 (r3) que aconteceu em 20070421 21:16:11 0300 que foi em um Sábado, 21 de Abril de 2007 Sat, 21 Apr 2007.
Para obter todas as mensagens de log:
% svn log http://svn.dominio.com.br/svn/projeto01/LEIAME.txt
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil commit de teste
Este e o meu primeiro commit, estou iniciando o repositorio projeto01 e importando os dados iniciais.
Esses são os comandos necessários para administrar o servidor Subversion no dia
adia e também utilizálo. Outros comandos que você deve aprender usar são svn delete e svn revert, e também svnadmin restore. Para isso siga as referências de comandos indicadas na URL anterior.
Para se tornar um usuário pleno do sistema de repositórios, é importante praticar a aprender todos os comandos indicados na referência. Mas sabendo o apresentado aqui, com certeza você já terá base para uma boa experiência inicial com o ambiente de versão concorrente baseado em Subversion.
Agora você pode apontar seu navegador para http://svn.dominio.com.br/svn/projeto01/
E notará no navegador uma saída parecida com a seguinte:
Revision 3: /
•
LEIAME.txt
--------http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Powered by Subversion version 1.4.0 (r21228).
Aumentando a Segurança do Subversion com SSL
O Subversion como anteriormente citado pode trabalhar com diversos protocolos, desde servidor svn nativo – o svnserve – até em conjunto com Apache utilizando WEB_DAV, que é a implementação que fizemos aqui. Essa implementação é a mais indicada pelo time de desenvolvedores do Subversion, e é a mais flexível. Um efeito adicional dela é que você pode a qualquer momento configurar o Apache para trabalhar com protocolo SSL/TLS, da maneira convencional – não há nenhuma modificação especial para o Subversion – e uma vez tendo habilitado o SSL, basta utilizar https:// nos comandos svn pois a aplicação svn tem suporte pleno a transações sobre SSL.
Interface Web
Normalmente sistemas de versionamento concorrente, em especial CVS tem um recurso muito interessante, uma interface Web que permite que usuários anônimos (ou autenticados, quando configurado para tal) naveguem por toda a árvore dos repositórios, copiem qualquer arquivo que desejar, e possam acompanhar as informações de logs e datas de cada modificação, bem como tirar diff entre revisões arbitrárias de cada arquivo ou estrutura. Esse sistema chamase webcvs ou cvsweb. A implementação mais famosa e mais adotada é o cvsweb criado pelo Projeto FreeBSD e liberado publicamente sob licença BSD.
O Subversion tem um ambiente web nativo, embarcado no módulo svn_dav como já percebemos, porém, existe uma iniciativa ainda mais completa para o Subversion, que se destaca frente a qualquer interface Web de repositórios, sejam sistemas proprietários ou outros livres.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Estamos falando do Trac, uma interface Web que integra o SCM Subversion, sistema de Tickets de problemas, Wiki e outros recursos de Gerência de Projetos de Software. É uma interface criada por uma comunidade de consultores e desenvolvedores de Software chamada EdgeWall. O Trac é uma excelente ferramenta complementar ao Subversion.
Abordaremos sua instalação e configuração na segunda parte desse artigo.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil PARTE II TRAC
Introdução
TRAC é um projeto que cumpre com louvor o objetivo de integrar recursos de (1) acompanhamento e gerência de problemas no desenvolvimento de um software ou relatos de erros em qualquer outro documento, programa ou arquivo sendo trabalhado em um sistema de versionamento concorrente, ao mesmo tempo em que oferece (2) um sistema de Wiki completo, propício para documentação colaborativa do ítem sendo trabalhado; oferece ainda (3) um sistema de linha cronológica do desenvolvimento e evolução de projetos, com milestones prédefinidos, e por fim, (4) uma interface Web para explorar completamente um repositório Subversion.
TRAC integra o SCM Subversion, sistema de Tickets de problemas, Wiki e outros recursos de Gerência de Projetos de Software. É uma interface criada por uma comunidade de consultores e desenvolvedores de Software chamada EdgeWall. O Trac é uma excelente ferramenta complementar ao Subversion, e combinados oferecem ambiente completo para gerência e desenvolvimento concorrente de projetos.
Como se não bastasse, TRAC oferece ainda uma extensível interface para gerenciamento de plugins, possibilitando incorporação de recursos adicionais, criados pela comunidade ou pelos próprios desenvolvedores TRAC.
TRAC é desenvolvido em python, e pode ser utilizado em modo independente (standalone) através do servidor web builtin, o tracd(8), ou através do servidor Web Apache, em modo CGI, como FastCGI, com mod_python ou ainda com mod_wsgi, um adaptador WSGI para Apache, criado pelo Google – ainda experimental.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Objetivo
Ao longo desse artigo instalaremos o TRAC para trabalhar com mod_python, no Apache, pois esta é a implementação que oferece maior performance e estabilidade. Utilizaremos o TRAC com suporte a SQLite3, e instalaremos o plugin de administração Web do TRAC.
Nosso setup implementará uma configuração do Trac que permite a criação de múltiplas instâncias do sistema, um para cada projeto/repositório, exatamente para integrar da forma mais completa possível o TRAC com o subversion.
Instalação do TRAC
O TRAC depende do python em nosso sistema, e também de uma base de informação onde todos os dados referentes a ele estarão disponíveis. Essa base de informação por padrão é o SQLite3, mas o TRAC também pode ser instalado com suporte a PostgreSQL ao invés de SQLite3, e também MySQL. Contudo o suporte a MySQL é considerado experimental.
Dependências
O TRAC pode trabalhar em modo independente, onde um daemon chamado tracd(8) implementa um servidor Web em Python. Essa contudo é a menos indicada implementação pois oferece poucos recursos de segurança, e principalmente baixíssima performance. http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Complementarmente pode trabalhar em modo CGI ou FastCGI com qualquer servidor Web que suporte esses métodos. Mas o mais indicado é que o servidor de escolha seja o Apache2, nesse caso, o TRAC pode trabalhar com o mod_python3 ou mod_wsgi, um adaptador WSGI para Apache, criado pelo Google, que em teoria pode ter performance superior ao mod_ptyhon3, mas que ainda é considerado experimental e tem pequenos problemas de instabilidade.
Portanto nossa implementação será com mod_python3, devida a reconhecida estabilidade e excelente performance, com conjunto com Apache2. Nossa base de informação será a primária para o TRAC, SQLite3, mas a seu critério pode optar por outra base, preferencialmente PostgreSQL, se o sistema já estiver disponível localmente. Do contrário não é justificável substituir o SQLite3, pois este traz excelente performance para o tipo de operação que o TRAC demanda, e principalmente por ser uma base de dados lightweight (leve), pequena e estável. Portanto nossa lista de dependências inclui:
•
Python
•
mod_python3 para Apache2
•
SQLite3
•
PostgreSQL (em substituição ao SQLite3)
•
MySQL (experimental, em substituição ao SQLite3) Instalando o mod_python3
mod_python3 é o suporte DSO ao Apache2 para trabalhar nativamente com handlers Python; nesse momento, se seu sistema ainda não tiver Python, ele será instalado como dependência. A instalação deste módulo DSO é extremamente facilitada http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil pela Coleção de Ports do FreeBSD, basta:
# cd /usr/ports/www/mod_python3/
# make install clean
Ao final da instalação você observará a seguinte mensagem da Coleção de Ports:
================================================================================
Also remember to add to your Apache configuration in the appropriate context:
PythonPath "['/path/to/foo', '/path/to/bar']"
AddHandler python-program .py
PythonHandler foobar
PythonDebug On
For more information, see http://www.modpython.org/.
================================================================================
Indicando que você configure seu httpd.conf com essas entradas. Isso porquê o mod_python3 oferece ao Apache2 um recurso que permite que qualquer arquivo com extensão .py seja interpretado e processado nativamente, o mesmo tipo de abordagem que o mod_php faz para arquivos de extensão .php por exemplo.
Nós não precisaremos adicionar essas entradas ao httpd.conf para utilizarmos o TRAC, pois configuraremos o Handler de maneira um pouco mais específica. Porém, se você pretende ter recurso de suporte a Python em seu servidor Web, pode aproveitar a oportunidade e fazêlo desta forma.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Instalando o TRAC
Através da Coleção de Ports do FreeBSD, vamos instalar o TRAC, portanto entre na estrutura de ports do trac e dê um make config:
cd /usr/ports/www/trac/
make config
Garanta que as opções SILVERCITY e DOCUTILS estejam marcadas, elas dão suporte a destaque de sintaxe e recursos especiais de marcação, ambos úteis no ambiente Wiki do TRAC. Garanta que SUBVERSION também esteja marcado, e se quiser marque PostgreSQL caso prefira utilizálo em substituição ao SQLite3. A saída do comando make showconfig deve apresentar:
# make showconfig
===> The following configuration options are available for trac-0.9.6:
SILVERCITY=on "Use Silvercity for syntax highlighting"
DOCUTILS=on "Allow additional text markup"
PGSQL=Off (default) "Use PostgreSQL instead of SQLite3"
SUBVERSION=On (default) "Support for subversion RCS"
===> Use 'make config' to modify these settings
Estando na estrutura do port, agora instale o TRAC:
# pwd
/usr/ports/www/trac
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil # make install clean
Ao término da instalação note que o port instalou uma importante dependência, o port subversionpython:
# pkg_info | grep -i subversion-python
subversion-python-1.4.3_2
Version control system
Pronto, o TRAC está devidamente instalado.
Criando um Projeto no TRAC
TRAC sempre dependerá de uma estrutura no sistema de arquivos onde os projetos estarão disponíveis, e nessa estrutura o banco de dados SQLite3, os conectores e os recursos individuais para cada projeto distinto, gerenciado pelo TRAC, se encontrarão. Então, seguindo a organização inicialmente planejada para o Subversion, devemos criar também uma estrutura base onde todos nossos Projetos gerenciados pelo TRAC estarão. Para seguir a padronização adotada, criaremos o /usr/home/trac:
# mkdir /usr/home/trac
Para criar um novo projeto no TRAC, utilizamos o comando trac-admin, com o argumento initenv. Para conhecer o trac-admin e suas outras opções, use:
trac-admin help
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Note através do help que a sintaxe desejada é
svn-admin <caminho/para/projeto> <comando>
Onde <comando> será initenv;
Como nosso repositório existente até o momento é o projeto01, vamos criar um ambiente de gerência TRAC para esse repositório:
# svn-admin /usr/home/trac/projeto01 initenv
Note que para criar o ambiente de gerência TRAC para o Projeto, uma série de perguntas serão feitas. A primeira será qual o nome do projeto, preencha conforme destacado:
Project Name [My Project]> Projeto 01
As próximas duas perguntas serão o tipo de conexão com base de dados. Mantenha o padrão indicado apenas confirmando com ENTER; e depois qual o repositório, mantenha o padrão (SVN) apenas confirmando com ENTER:
Database connection string [sqlite:db/trac.db]> <pressione ENTER>
Repository type [svn]> <pressione ENTER>
Agora a pergunta mais importante, qual o caminho para o repositório Subversion a que este Projeto se refere:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Path to repository [/path/to/repos]> /usr/home/svn/projeto01
Por último, confirme o diretório dos Templates:
Templates directory [/usr/local/share/trac/templates]> <pressione ENTER>
Ao concluir a inicialização do ambiente, note uma mensagem similar a:
Project environment for 'Projeto 01' created.
You may now configure the environment by editing the file:
/usr/home/trac/projeto01/conf/trac.ini
If you'd like to take this new project environment for a test drive,
try running the Trac standalone web server `tracd`:
tracd --port 8000 /usr/home/trac/projeto01
Then point your browser to http://localhost:8000/projeto01.
Portanto podemos testar se a criação de nosso ambiente foi completada com sucesso de forma muito simples, iniciando o TRAC em modo independente (standalone) que apesar de oferecer baixa performance, é muito apropriado para um teste rápido. Então inicie o trac daemon com os argumentos indicados:
tracd --port 8000 /usr/home/trac/projeto01
E aponte seu navegador para a URL http://svn.dominio.com.br:8000/. Note que o http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil trac daemon listará todos os projetos disponíveis, que você passou como argumento na linha de comando, então você observará em seu navegador um link para Projeto 01 que te levará para http://svn.dominio.com.br:8000/projeto01.
Bemvindo ao TRAC! Essa é a aparência do ambiente Web, e você pode testalo, começando por fazer uma modificação no Wiki. Clique no botão Edit this page e na primeira linha do formulário de edição do Wiki coloque:
= Minha Primeira Edição no Wiki do TRAC =
Um texto qualquer
Como no screenshot:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Salve, e observe os resultados, serão similares a:
Utilizando o daemon tracd
O tracd(8) não é indicado para ambientes com muitos usuários por ter performance muito baixa. Contudo, para um ambiente de desenvolvimento residencial ou pequena empresa, onde poucos usuários utilizarão o TRAC para apenas um ou poucos projetos, o tracd(8) pode ser apropriado, já que nessas circunstâncias não demandará alta performance, com poucos usuários e poucos projetos utilizando TRAC.
Se desejar pode rodar o tracd para gerenciar seu projeto. Nesse caso as próximas instruções, que referemse à configuração do Apache2 e mod_python3 para o TRAC podem ser puladas. Para usar o tracd em produção é indicado que usemos http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil adicionalmente os argumentos -r, para sempre acompanhar modificações nos projetos, -d para entrar em modo daemon e --pidfile para gerar um arquivo de PID. O ideal, por segurança, é rodar o daemon com usuário desprivilegiado, pode ser o seu usuário por exemplo. Nesse caso, como root você pode digitar:
setuidgid seu_usuario tracd -r -d --port 8000 --pidfile=/var/run/tracd.pid
/usr/home/trac/projeto01
Para matar o daemon depois bastará:
kill -9 `cat /var/run/tracd.pid`
Leia a página de manual rc(8) para obter exemplo de como criar seu script de inicialização apropriadamente, e colocandoo como /usr/local/etc/rc.d/tracd
sempre iniciar o daemon do TRAC nas inicializações de seu servidor.
Por último, os projetos geridos pelo tracd precisam garantir acesso de leitura e escrita no database para o usuário executando o tracd, então você deve:
chown -R seu_usuario /usr/home/trac/projeto01/db
E, se estiver utilizando mod_python no Apache (como veremos a seguir):
chgrp -R svn /usr/home/trac/projeto01/db
chmod -R g+rw /usr/home/trac/projeto01/db
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Configurando mod_python
Agora para garantir que o mod_python está devidamente instalado, edite seu arquivo de configuração httpd.conf:
vi /usr/local/etc/apache2/httpd.conf
Procure o final do bloco LoadModule, e adicione a seguinte entrada:
LoadModule python_module
libexec/apache2/mod_python.so
Em seguida, procure onde anteriormente foi adicionada a entrada <Location /svn> e antes dela adicione o seguinte <Location> de teste:
# Apenas para testar mod_python, comentar depois.
<Location /py-info>
SetHandler mod_python
PythonHandler mod_python.testhandler
</Location>
Esta entrada serve exclusivamente para que possamos testar a disponibilidade e funcionamento do mod_python no Apache2. Fazendo uma analogia direta, é o mesmo tipo de testes que, na linguagem PHP, podemos fazer com a função phpinfo(); então http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil após adicionar a entrada, reinicie seu Apache:
apachectl stop
apachectl start
E direcione seu navegador web para o endereço http://svn.dominio.com.br/py
info. Se tudo estiver adequadamente instalado,você observará uma página similar a seguinte:
General information
Apache version
Apache
Apache threaded MPM
Yes (up to 128 threads per process)
Apache forked MPM
Yes, maximum 870 processes
Apache server root
/usr/local
Apache document root
/usr/local/www/data
Apache error log
/var/log/httpd-error.log (view last 100 lines)
Python sys.version
2.4.4 (#1, Apr 22 2007, 05:48:55) [GCC 3.4.6
[FreeBSD] 20060305]
Python sys.path
/usr/local/lib/python24.zip
/usr/local/lib/python2.4
/usr/local/lib/python2.4/plat-freebsd6
/usr/local/lib/python2.4/lib-tk
/usr/local/lib/python2.4/lib-dynload
/usr/local/lib/python2.4/site-packages
Python interpreter name
svn.dominio.com
mod_python.publisher
available
Yes
mod_python.psp available
Yes
Seguida de mais uma série de blocos de informações adicionais. Nesse caso sua instalação e testes foram completados com sucesso, você pode remover do Apache o http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil bloco <Location /py-info>, pois essas informações não devem ser observadas publicamente, ou então restringir o acesso a esse <Location> através dos dispositivos de controle de acesso do Apache, por exemplo, se quiser liberar o acesso a esse endereço de testes apenas a uma rede confiável (nesse exemplo, 10.69.69.0/24) façao por exemplo da seguinte forma:
<Location /py-info>
PythonHandler mod_python.testhandler
Order deny,allow
Deny from all
Allow from 10.69.69.0/24
</Location>
Então você pode manter esse <Location> seguramente.
Agora finalmente, a configuração que nos interessa de fato. Vamos criar um ambiente com um <Location>
apontando para /projetos. Esse <Location
/projetos> utilizará o mod_python como handler de códigos no Apache, para que os dados neste endereço sejam processados com o interpretador adequado da linguagem python.
Então
definimos
o
PythonHandler
chamando
o trac.web.modpython_frontend que é o módulo principal do TRAC.
Então definimos através das directiver
PythonOption as variáveis TracEnvParentDir apontando para a base onde encontramse nossos projetos TRAC, e a TracUriRoot para a URL em nosso servidor, no caso o mesmo endereço de <Location>, ou seja, /projetos. Por último adicionaremos (apenas por garantia, já http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil que de forma geral isso não seria preciso, devido a forma como o ports do FreeBSD instala o TRAC) ao PATH do Python o caminho para todos os arquivos Python que compõe o TRAC, usando a directiva PythonPath:
<Location /projetos>
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /usr/home/trac
PythonOption TracUriRoot /projetos
PythonPath "sys.path + ['/usr/local/lib/python2.4/site-packages/trac']"
# PythonDebug On # apenas em caso de problemas
</Location>
Vale a pena mencionar que TracUriRoot não é necessário se você tem DNS devidamente configurado e o ServerName do Apache indica uma entrada com DNS válido. Em todo caso não há problemas ou consumo adicional de recursos em adicionar essa opção, portanto vale a pena mantêla. O endereço /projetos foi escolhido por organização e exemplo, se preferir use outro endereço, como /trac, ou o que desejar em seu ambiente de produção. Lembrese de modificar tanto no <Location> quanto TracUriRoot. Se preferir é possível ainda criar um VirtualHost só para o TRAC (exemplo ao longo dessa seção do documento).
Por último, um truque simples utilizando o LocationMatch do Apache. Vamos garantir
que
sempre
que
algum
endereço
http://svn.dominio.com.br/projetos/<qualquer_projeto>/login no
formato seja acessado, o Apache solicitará autenticação, e apontaremos qual arquivo de autenticação usar. Isso porquê o TRAC não tem um sistema de login flexível, mas suporta plenamente sistema de autenticação do Apache, que inclusive é o método oficialmente mais recomendado pelo Projeto TRAC.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil E para garantir plea compatibilidade e integração com o Subversion, utilizaremos exatamente o mesmo arquivo de sejas que o Subversion através do SVN_DAV utiliza, o /usr/local/etc/svnpasswd. Assim sendo, logo abaixo do
<Location
/projetos> adicione a seguinte entrada:
<LocationMatch "/projetos/[^/]+/login">
AuthType Basic
AuthName "Gerenciador de Projetos Trac (svn.dominio.com.br)"
Require valid-user
</LocationMatch>
Ótimo, agora reinicie o Apache:
apachectl stop
apachectl start
E aponte seu navegador para http://svn.dominio.com.br/projetos/. Se você obter um erro de permissão, dizendo que o usuário deve ter acesso de leitura e escrita, não se preocupe. É esperado. Para cada Projeto TRAC, dê as permissões adequadas de acordo com nossa estratégia de permissões adotada:
chgrp -R svn /usr/home/trac/<projeto>/db
chmod -R g+rw /usr/home/trac/<projeto>/db
Começando portanto de nosso primeiro projeto:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil chgrp -R svn /usr/home/trac/projeto01/db
chmod -R g+rw /usr/home/trac/projeto01/db
Ótimo,
agora
recarregue
seu
navegador
no
endereço http://svn.dominio.com.br/projetos/ e todos os projetos aparecerão listados.
Como só temos um nesse momento, clicandoo você será levado para http://svn.dominio.com.br/projetos/projeto01,
e nele está todo o ambiente TRAC prontinho para ser usado.
Colocando o TRAC em um domínio virtual.
Para configurar todo esse ambiente em um domínio virtual, é muito simples. Basta configurar o domínio virtual normalmente, e colocar o
<Location> e <LocationMatch> dentro do container <VirtualHost>, e apenas fazer uma modificação: garantir que <Location> e TracUriRoot apontem ambos para a raiz do domínio virtual, ou seja, para /
NameVirtualHost <IP_DO_APACHE>
<VirtualHost IP_DO_APACHE>
DocumentRoot /usr/home/trac
ServerName projetos.dominio.com.br
ServerAlias trac.dominio.com.br
ServerAdmin [email protected]
CustomLog /var/log/projetos.dominio.com.br-access_log common
ErrorLog /var/log/projetos.dominio.com.br-error_log
<Location />
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil PythonHandler trac.web.modpython_frontend
PythonOption TracUriRoot /
PythonPath
"sys.path
+
['/usr/local/lib/python2.4/site-
packages/trac']"
# PythonDebug On # apenas em caso de problemas
</Location>
<LocationMatch "/projetos/[^/]+/login">
AuthType Basic
AuthName "Gerenciador de Projetos Trac (svn.dominio.com.br)"
Require valid-user
</LocationMatch>
Sem mistérios ou segredos, simplesmente configurado. Ainda, se o TRAC for ser usado em um ambiente com SSL adicione no <VirtualHost> ou na configuração global do Apache, ou ainda no bloco <Location>:
SetEnv HTTPS 1
Usando o TRAC
Clicando
em
Browse
Source você
http://svn.dominio.com.br/projetos/projet01/browser, será
levado
para e nele encontrará todos os arquivos de nosso repositório (portanto, pelo menos o LEIAME.txt), e agora través de uma interface Web extremamente amigável poderá explorar os arquivos, leros registros de logs de commit e também comparar as modificações entre revisões arbitrárias da árvore do repositório.
A partir desse momento cabe apenas a você, ler a documentação do TRAC e http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil aprender a usálo adequadamente. Sua própria instalação do TRAC já traz toda a documentação que você precisa, a saber:
http://svn.dominio.com.br/projetos/projeto01/wiki/TracWiki
http://svn.dominio.com.br/projetos/projeto01/wiki/TracBrowser
http://svn.dominio.com.br/projetos/projeto01/wiki/TracChangeset
http://svn.dominio.com.br/projetos/projeto01/wiki/TracTickets
http://svn.dominio.com.br/projetos/projeto01/wiki/TracReports
http://svn.dominio.com.br/projetos/projeto01/wiki/TracQuery
http://svn.dominio.com.br/projetos/projeto01/wiki/TracRoadmap
http://svn.dominio.com.br/projetos/projeto01/wiki/TracTimeline
Nesse momento, explore a instalação atual do TRAC ao máximo para conhecêlo em detalhes. Acompanhe alguns screenshots de uso do Browser do TRAC:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Clicando em View Changes você pode observar as mudanças que ocorreram entre visões da árvore. Por exemplo, acima vemos como obter uma visão geral das mudanças entre a Revisão 4 e a Revisão 17. E depois temos o resultado:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil E no próximo shot temos detalhes das modificações entre a Revisão 1 e a Revisão 6, observamos a legenda indicado arquivos adicionados e modificados, e configurando para observar as mudanças ladoalado (side by side) visualizamos facilimente o que mudou entre essas duas revisão arbitrárias:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Usando o TRAC em Português Brasileiro
Infelizmente Internacionalização não foi um recurso pensando no projeto de desenvolvimento do TRAC desde seu princípio, e apenas nas versões mais atuais o subsistema de I18N e L10N vem sendo pensado, discutido e projetado. O resultado é que há pouca documentação oficial do TRAC em português brasileiro, e como não há uma maneira adequada de fazer a tradução, apenas um recurso resta: a tradução do template utilizado.
Você notou que durante a criação do projeto TRAC com tracadmin, foi solicitado o caminho para os templates. A qualquer momento você pode redefinir esses templates, mesmo em um projeto TRAC já em produção.
Um brasileiro, Fábio David Batista, traduziu os templates do tema padrão do TRAC para português brasileirl, na versão 0.9.1 do TRAC. Apesar de estarmos já na série 0.10.X do TRAC, o template em questão mostrase bastante funcional e poucas expressões não estão traduzidas, então podemos utilizalo. Para isso crie a estrutura de templates em nossa língua:
# mkdir /usr/local/share/trac/templates-pt_br
Nesse diretório, baixe o template traduzido por Fábio e descompacteo:
#
fetch
-o
trac-0.9.1-templates-pt-br.tar.gz
"http://trac.edgewall.org/attachment/wiki/TracL10N/trac-0.9.1templates-pt-br.tar.gz?format=raw"
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil # tar xzf trac-0.9.1-templates-pt-br.tar.gz
Pronto, agora basta configurar seu Projeto para utilizar esses templates, através do arquivo de configuração do TRAC, o trac.ini, sempre disponível em:
/usr/home/trac/<projeto>/conf/trac.ini
Portanto edite o /usr/home/trac/projeto01/conf/trac.ini e procure pela entrada templates_dir, que esta comentada, dentro do bloco [trac]:
templates_dir = /usr/local/share/trac/templates-pt_br
Não é preciso reiniciar o Apache. Recarregue seu navegador e o TRAC estará em português – as informações do TRAC em sí, e não o conteúdo das páginas Wiki nem a documentação.
O arquivo de configuração do TRAC – trac.ini
Agora você já conhece o trac.ini, mas é hora de estudálo em mais detalhes. Primeiro, saiba que todo projeto TRAC terá seu próprio trac.ini, sem disponível em <projeto>/conf/trac.ini
Portanto em nosso ambiente, sempre em
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil /usr/home/trac/<projeto>/conf/trac.ini
Há ainda a possibilidade de criar um arquivo trac.ini global (que por padrão não existe) em /usr/local/share/trac/conf/trac.ini, que não tem precedência alguma sobre a configuração específica de cada ambiente, possibilitando e defeinições de padronização clara para todos os projetos, sem evitar a customização de opções de forma seletiva.
O trac.ini é bem simples. Sua configuração é dividia em [blocos] e em cada [bloco] definimos opcao = valor, uma opcao por linha.
Acesse o endereço http://svn.dominio.com.br/projetos/projeto01/wiki/TracIni para observar uma descrição completa de cada opção, cada [bloco] e os tipos de valores de cada opção do trac.ini.
No bloco [trac] configure o suporte aos arquivos de política do Subversion, e identifique também a que regras de acesso de repositório o qual este TRAC deve sucumbir:
[trac]
authz_file = /usr/local/etc/svn_authz.conf
authz_module_name = projeto01
...
...
Se desejar habilitar o recurso de log do TRAC, modifique o bloco [logging] da seguinte forma:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil [logging]
log_file = trac.log
log_level = DEBUG
log_type = file
E os logs passarão a ser gerados em /usr/home/trac/<projeto>/log. Portanto o Apache deve ter acesso de escrita nesse diretório:
# chgrp -R svn /usr/home/trac/projet01/log
# chmod -R g+rw /usr/home/trac/projet01/log
Os blocos [header_logo] e também [project] são candidatos em potencial para customização do TRAC, incluindo URL, nome do Projeto e imagem para ser usada como logotipo na apresentação do TRAC. Adeque esses blocos como desejar.
Gerenciando Permissões no TRAC
Se a integração com os arquivos authz do Subversion não atender suas necessidades, é possível gerenciar ainda as permissões do TRAC de forma seletiva, através do comando trac-admin com o argumento permission. Sua sintaxe é
trac- admin < /caminho /projeto > permission <add|remove|list> <usuario|grupo > <privilegio>
Existe ainda uma sintaxe alternativa, que permite adicionar ou remover usuários a grupos:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil trac- admin < /caminho /projeto > permission <add|remove> <usuario> <grupo>
A lista de <privilegios> e também exemplos de uso podem ser observados em
http://svn.dominio.com.br/projetos/projeto01/wiki/TracPermissions
Por exemplo, listemos as permissões atuais nativas do TRAC em nosso projeto:
# trac-admin /usr/home/trac/projeto01/ permission list
User
Action
-------------------------anonymous
BROWSER_VIEW
anonymous
CHANGESET_VIEW
anonymous
FILE_VIEW
anonymous
LOG_VIEW
anonymous
MILESTONE_VIEW
anonymous
REPORT_SQL_VIEW
anonymous
REPORT_VIEW
anonymous
ROADMAP_VIEW
anonymous
SEARCH_VIEW
anonymous
TICKET_CREATE
anonymous
TICKET_MODIFY
anonymous
TICKET_VIEW
anonymous
TIMELINE_VIEW
anonymous
WIKI_CREATE
anonymous
WIKI_MODIFY
anonymous
WIKI_VIEW
Available actions:
BROWSER_VIEW, CHANGESET_VIEW, CONFIG_VIEW, FILE_VIEW, LOG_VIEW,
MILESTONE_ADMIN, MILESTONE_CREATE, MILESTONE_DELETE, MILESTONE_MODIFY,
MILESTONE_VIEW, REPORT_ADMIN, REPORT_CREATE, REPORT_DELETE, REPORT_MODIFY,
REPORT_SQL_VIEW, REPORT_VIEW, ROADMAP_ADMIN, ROADMAP_VIEW, SEARCH_VIEW,
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil TICKET_ADMIN, TICKET_APPEND, TICKET_CHGPROP, TICKET_CREATE, TICKET_MODIFY,
TICKET_VIEW, TIMELINE_VIEW, TRAC_ADMIN, WIKI_ADMIN, WIKI_CREATE,
WIKI_DELETE, WIKI_MODIFY, WIKI_VIEW
Vamos por exemplo remover do usuário anônimo o direito de criar ou modificar páginas Wiki:
# trac- admin /usr / home / t rac /projeto01 / permission remove anonymous WIKI_CREATE
# trac- admin /usr / home / t rac /projeto01 / permission remove anonymous WIKI_MODIFY
Vamos adicionar o usuário patrick ao grupo1 e definir privilégios do Wiki para o grupo1:
# trac- admin /usr / home / t rac /projeto01 / permission add patrick grupo1
# trac- admin /usr / home / t rac /projeto01 / permission add grupo1 WIKI_MODIFY WIKI_DELETE
WIKI_CREATE WIKI_ADMIN
E assim podemos criar políticas consistentes de acesso sem depender do arquivo de configuração do Subversion, se você jugar conveniente.
Instalando o Plugin Webadmin
Ficou preocupado em ter que ficar definindo permissões manualmente em cada Projeto? Simples, defina um usuário administrador do Projeto e instale o plugin Webadmin, que permite que todos os controles feitos pelo comando tracadmin sejam desempenhados pela interface Web do TRAC.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Para isso instale o plugin em questão pela Coleção de Ports do FreeBSD:
# cd /usr/ports/www/trac-webadmin/
Depois, é necessário configurar uma entrada a mais no <Location /projetos>, no /usr/local/etc/apache2/httpd.conf, a entrada:
SetEnv PYTHON_EGG_CACHE /usr/local/lib/python2.4/site-packages/
O bloco em questão ficará assim:
<Location /projetos>
PythonHandler trac.web.modpython_frontend
PythonOption TracUriRoot /projetos
PythonPath "sys.path + ['/usr/local/lib/python2.4/site-packages/trac']"
SetEnv PYTHON_EGG_CACHE /usr/local/lib/python2.4/site-packages/
</Location>
Em seguida edite o /usr/home/trac/projeto01/conf/trac.ini e no final do arquivo adicione:
[components]
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil webadmin.* = enabled
Ótimo, está quase tudo pronto. Agora basta eleger um usuário administrador e dar a ele dois privilégios, o TRAC_ADMIN e TICKET_ADMIN. Por exemplo, para tornar patrick administrador pela interface Web do projeto01:
# trac-admin /usr/home/trac/projeto01/ permission add patrick TRAC_ADMIN
TICKET_ADMIN
Prontinho, agora quando patrick se logar no TRAC do projeto01, uma nova opção aparecerá na aba do TRAC, a opção Admin, que levará o usuário ao endereço:
http://svn.dominio.com.br/projetos/projeto01/admin
E por último, o Apache deverá poder escrever as configurações em <projeto>/conf:
# chmod -R g+rw /usr/home/trac/projeto01/conf
# chgrp -R svn /usr/home/trac/projeto01/conf
Tudo pronto. Se desejar oferecer esse recurso a outros projetos também, pode colocar a directive [components] em questão no arquivo trac.ini global, como documentado anteriormente.
O único recurso do Webadmin que não estará disponível é o recurso de instalação de outros plugins pela Web. Isso porquê ele precisa de privilégios de escrita no diretório http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil onde os plugins serão instalados, e este diretório por padrão é acessível apenas ao usuário root, é o mesmo diretório apontando por SetEnv PYTHON_EGG_CACHE, ou seja o:
/usr/local/lib/python2.4/site-packages/
Não recomendamos que o Apache tenha privilégio de escrita nesse diretório.
No screenshot abaixo observamos como a configuração geral do Projeto no TRAC tornase trivial com esse plugin.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil E no próximo screenshot observamos os detalhes de outros plugins instalados:
Instalando o Plugin TRAC Gantt
Quem é acostumado com gerência de projetos sabe que uma das obrigações em qualquer abordagem formal padrão PMI (Project Management Institute) demanda gráficos Gantt documentando timeline e schedules de evolução do projeto. O plugin trac-gantt oferece a possibilidade de criar gráficos Gantt para todos os tickets de problemas encontrados no gerenciador de tickets do TRAC. Um recurso extremamente útil e poderoso. Altamente recomendada instalação desse plugin, que através da Coleção de Ports do FreeBSD é simples:
# cd /usr/ports/www/trac-gantt/
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Edite o trac.ini e no bloco [ticket] adicione 12 novos campos ao sistema de tickets, os campos em destaque:
[ticket]
default_component =
default_milestone =
default_priority = major
default_type = defect
default_version =
restrict_owner = false
# Plugin que gera mapas Gantt
due_assign = text
due_assign.label = Due to assign
due_assign.value = DD/MM/YYYY
dependencies = text
dependencies.label = Dependencies
dependencies.value =
due_close= text
due_close.label = Due to close
due_close.value = DD/MM/YYYY
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil include_gantt = checkbox
include_gantt.label = Include in GanttChart
include_gantt.value =
No bloco [components] habilite este plugin, como feito com o webadmin:
[components]
webadmin.* = enabled
tracgantt.* = enabled
E por último no final do arquivo, crie um bloco chamado [ganttcharts] com o seguinte conteúdo:
[gantt-charts]
date_format = %m/%d/%Y
include_summary = true
summary_length = 16
use_creation_date = true
show_opened = true
Ao ativar o plugin dois novos atributos de permissão estarão disponíveis no TRAC, os atributos GANTT_VIEW e GANTT_ADMIN.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Por padrão o usuário anonymous por exemplo, não poderá sequer visualizar os gráficos Gantt gerados pelo plugin. Se desejar, dê privilégio para outros usuários administrarem o plugin, mas o menos permissão de visualizar os gráficos ao usuário anônimo.
Você pode fazer isso com o trac-admin, que já conhece, ou agora pela interface de administração web, como no screenshot a seguir:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Outros Plugins na Coleção de Ports
Existem outros plugins na Coleção de Ports que podem ser interessante ao seu ambiente, todos consideravelmente fáceis de configurar e de instalação praticamente automática pelo Ports. São eles:
•
/usr/ports/www/trac-accountmanager – permite que um usuário registre e gerencie múltiplas contas;
•
/usr/ports/www/trac-addcomment – permite que sejam adicionados comentários em páginas Wiki; suporta formatação Wiki; torna o TRAC uma espécie de CMS com interatividade do visitante através de comentários;
•
/usr/ports/www/trac-bzr – adiciona suporte ao repositório Bazaar;
•
/usr/ports/www/trac-ctxtnavadd/ Permite a criação de novos links em baixo da barra primária de navegação;
•
/usr/ports/www/trac-down – Permite listagem automática de downloads lançados;
•
/usr/ports/www/trac-gantt
– Comentado e adicionado neste documento;
•
/usr/ports/www/trac-nav – Implementa barra de navegação no Wiki; já disponível desde a versão 0.10 do TRAC e portanto dispensável;
•
/usr/ports/www/trac-pagetopdf – permite que as páginas Wiki do TRAC sejam exportadas para PDF e posterior download;
•
/usr/ports/www/trac-privatetickets – Adiciona controle por ticket de problemas, possibilitando que usuários só vejam os tickets atribuídos a eles;
•
/usr/ports/www/trac-robotstxt – Serve um arquivo robots.txt; para usar com tracd(8);
/usr/ports/www/trac-tags – Implementa o conceito de tags para agrupar assuntos ou tópicos;
•
/usr/ports/www/trac-webadmin – Já documentado e instalado nesse documento; será integrado nativamente ao TRAC a partir da versão 0.11;
•
/usr/ports/www/trac-wikinotification – permite que usuários (inclusive anônimos quando definem um endereço de email) sejam notificados sobre a atualização de qualquer página Wiki;
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil PARTE III – TortoiseSVN
Introdução
Nessa última etapa, faremos uma introdução ao TortoiseSVN. Essa aplicação é na verdade uma extensão à API do Windows Explorer, e possibilita que através de janelas no Windows o usuário possa rápidamente fazer acesso à todas as operações do cliente SVN em uma shell integrada no clássico padrão Windows.
O TortoiseSVN é mantido pelo mesmo time que desenvolve o Subversion, e é a mais indicada ferramenta de produção para ambiente de trabalho baseado em Windows, e adequado para um ambiente onde temos um servidor FreeBSD implementado com todas as funcionalidades que implantamos até o momento, mas os usuários não tem facilidade nem disponibilidade para aprender a usar aplicações de linha de comando como o CLI svn.
Ao simples clique do botão direito do mouse o usuário pode acessar todos os comandos do Subversion, sem limitações, e inclusive com algumas vantagens que o ambiente gráfico oferece, como possibilidade de acompanhar estatísticas de trabalho por usuário, ou gráficos do ciclo de de vida do projeto, seus arquivos e revisões.
O TortoiseSVN é portanto um frontend gráfico para o svn, com a vantagem de ser integrado à API do Windows. Para outras plataformas, inclusive Unix, temos outros frontend gráficos também, como os seguintes:
rapidsvn
•
esvn
•
kdesvn
Todos disponíveis na Coleção de Ports do FreeBSD, e os dois primeiros disponíveis também para plataforma Mac OS X.
O TortoiseSVN tem suporte a língua portuguesa através de uma extensão, o language pack, que instalaremos com a própria aplicação. É contudo necessário dizer que a tradução de expressões clássicas do ambiente de versionamento concorrente pode tornar o ambiente de trabalho menos intuitivo, por exemplo, ações que ao longo desse artigo desempenhamos frequentemente como checkout e commit são chamadas de Obter e Submeter. Portanto requer alguma atenção adicional se decidir usar o TortoiseSVN permanentemente em português.
Instalando TortoiseSVN
A instalação do TortoiseSVN é bastante simples. Para isso basta fazer o download do MSI (Microsoft Installler) apropriado, de acordo com a sua arquitetura (32 ou 64 bits), em http://tortoisesvn.net/downloads. Nesse endereço você pode fazer o download e conferir a assinatura MD5, como no screenshot a seguir:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Em seguida, após concluir o download, opcionalmente você pode desejar obter o download do Language Pack em Português Brasileiro, caso deseja usar o TortoiseSVN em nossa língua pátria. Contudo, atenhase as considerações iniciais, pois as expressões chaves em todo processo de trabalho com sistema de versionamento concorrente são também traduzidas pelo Language Pack. Além do Language Pack podemos obter também, por download, o Spellchecker, dicionário para verificação ortográfica, caso você queira garantir adequada correção em seus logs de commit. http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil O processo de instalação dáse da maneira mais convencional possível, no melhor estilo Windows: dois cliques e diversos next. A única observação é que você pode decidir não instalar o dicionário inglês, caso todas as mensagens de log sejam em português. Porém, se o projeto é trabalhado por pessoas distintas em países distintos, é comum que todas as mensagens de log sejam geradas em inglês. Nesse caso pode ser útil manter o dicionário. Mas vale lembrar que esses detalhes totalmente intrísecos apenas a seu ambiente de trabalho, e mais considerações sobre uso ou não de corretores ortográficos não serão feitas. Afinal nosso objetivo aqui é outro.
Por último, ao concluir a instalação o sistema vai solicitar que o Windows seja reiniciado. Reinicie, pois algumas bibliotecas e ícones alternativos devem ser carregados junto à API do Windows, e isso acontece no momento do boot.
Estando concluída a instalação, precisamos criar nosso ambiente de trabalho. Nesse momento remetase de volta aos conceitos sobre o ~/svn_root que discutimos anteriormente. O conceito é o mesmo, e o uso dos comandos em ambiente CLI serão agora desempenhados direto pelo Windows Explorer.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Preparando o Ambiente de Trabalho
Decida onde será sua raiz local do repositório Subversion. Assim como no ambiente CLI o indicado é ~/svn_root, indicados que crie um diretório svn_root/
em algum dispositivo de disco local, como C:\svn_root. Em nosso exemplo criamos o E:\svn_root. Desloquese a este diretório e clique com o botão direito. Você observará de uma a três opções a mais, sempre que clicar com o botão direito em um ambiente de diretórios da API do Windows Explorer. Essas serão as duas opções mais comuns, que poderão ser desempenhadas dadas as circunstâncias do diretório e um menu com todas as opções. Como não fizemos o checkout ainda, esta ação será uma das primeiras, veja o screenshot.
Portanto temos opção de fazer SVN Checkout nesse diretório, ou as outras opções que observamos no submenu TortoiseSVN.
Queremos fazer checkout. Então escolha a opção SVN Checkout garantindo que esteja dentro do diretório \svn_root.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Depois de escolher a opção em questão, como no destaque do screenshot ao lado, será solicitada a URL do servidor SVN.
Digite a mesma URL que estamos trabalhando tanto em ambiente de linha de comando quanto pelo Apache, ou seja, entre com http: / / svn.cliente.com.br /svn / projeto01
para fazer o checkout desse diretório, como no exemplo do screenshot abaixo. Note que é possível escolher apenas uma determinada revisão, ou fazer checkout apenas da raiz ao invés de recursivamente. Não é o que queremos. Desejamos fazer o checkout da raiz inteira desse
projeto
(HEAD) recursivamente.
Muito simples. Ao final do processo você terá feito checkout da árvore toda, e observará uma cópia exata em seu \svn_root
como está no repositório SVN remoto. O histórico de todos os arquivos baixados será apresentado e por último qual a revisão que você acaba de sincronizar localmente, como no screenshot abaixo.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Iniciando o Trabalho
A partir de agora você pode adicionar novas estruturas de trabalho à sua árvore, ou ainda trabalhar com base na estrutura atual, inclusive fazendo modificações diretamente em sua versão local da árvore SVN, ou de apenas um trecho da árvore se preferir fazer checkout parcial. Portanto o ambiente de trabalho pode ser permanentemente o do \cvs_root, e de fato isso tornará o processo mais ágil, aumentando a produtividade geral de trabalho.
No exemplo acima criamos duas novas estrutura de trabalho, mestrado/ e projetos/. Note que a estrutura SVN não conhece esses dois diretórios novos, então temos que, igualmente feito em ambiente linha de comando, adicionar a estrutura, recursivamente, à lista de arquivos da árvore Subversion. Para isso selecione as duas http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil novas estruturas, e com o botão direito escolha no submenu TortoiseSVN, a opção add. Isso é equivamente ao comando svn add no ambiente CLI (Command Line Interface), como no screenshot abaixo.
Uma lista prévia do que adicionar será apresentada, como no destaque ao lado. Desmarque arquivos que enventuamente você não queria enviar para o repositório SVN, como arquivos ocultos do Windows, a exemplo, o Thumbs.db. Clique OK
para confirmar a adição desses arquivos. Ao término do procedimento será apresentada a lista de todos os arquivos adicionados à lista, no repositório local. Nenhum desses arquivos foram http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil de fato adicionados, e não existem no repositório Subversion remoto. Então se um companheiro de trabalho fizer checkout ou update de sua árvore local contra o repositório remoto ele não obterá os dados adicionados. Isso porque os dados foram apenas agendados para ser adicionados, exclusivamente na versão local da árvore.
Isso fica bem claro no ambiente de trabalho do TortoiseSVN, pois os dados marcados para adição ficam com um sinal de adição azul ao lado do ícone do arquivo ou diretório (+). Observe no screenshot abaixo:
Para efetivar a adição, é hora de fazer o commit. O commit no ambiente TortoiseSVN não tem muita graça, e não há o romantismo de fazer um commit em linha de comando. Então, sem a menor graça mesmo, clique nos novos arquivos, marcandoos, e com o botão da direita escolha a opção SVN Commit como no screenshot ao lado.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil TortoiseSVN solicitará a mensagem de log. Não faça commit sem ao menos uma descrição curta da modificação, pois a análise de seus companheiros de trabalho e também a identificação daquela modificação, caso desejar restaurala no futuro.
Esse é o momento em que o sistema pela primeira vez observará que você deseja fazer uma modificação de escrita, e pela primeira vez o servidor Subversion através do módulo Apache SVN_DAV solicitará autenticação para fazer o acesso de escrita, exatamente como na linha de comando.
O TortoiseSVN possibilitará salvar usuário e senha, como no destaque. Note que apenas as estruturas marcadas para adição são fóco desse commit, então autentiquese com seu usuário e senha e conclua o commit.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Quando o commit for concluído, uma lista de todos os arquivos modificados (nesse caso, adicionados) será apresentada, e imediatamente você observará que o ícone de adição será substituido pelo sinal verde indicando que a árvore SVN local está em plena sincronia com a árvore
SVN remota, como no screenshot
lado.
ao Versionamento Concorrente Completo com Subversion
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Identificando Árvore Fora de Sincronia
Sempre que houver qualquer modificação local pendente em relação a estrutura remota na árvore, o TortoiseSVN identificará essa falta de sincronia com um ícone vermelho com uma exclamação. Vamos fazer uma modificação em um dos arquivos de trabalho de nosso exemplo, dentro da estrutura projetos/PMI-cliente_cseltda/.
Vamos fazer o commit. Note no screenshot os detalhes, indicando a falta de sincronia em algumas partes da estrutura local, e no próprio arquivo modificado.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Nesse momento cabese uma consideração bastante interessante. O TortoiseSVN e o Subversion são aplicações bem projetadas, e com recursos inteligentes. A qualquer momento, se desejar, podemos criar patches ou gerar diffs para análise posterior, ou análise imediata. Se você analisar a modificação entre diversas versões (revisões) se arquivos de texto, como códigosfonte, scripts e rotinas em geral, o TortoiseSVN abrirá um editor que permite visualizar, com destaques identificados por cor, as modificações entre as revisões sendo analisadas. Sem novidades até ai.
Porém, o Subversion é o sistema de versionamento concorrente que tem o melhor suporte a arquivos binários no mercado. Ele é capaz de salvar apenas a diferença, e remontar os arquivos na hora de apresentálos ao usuário. O TortoiseSVN por sua vez atualiza a API Windows Explorer de forma que, se possível, é utilizado sistema instalado localmente para analisar as modificações.
Então, clicando com o terceiro botão, indo no menu TortoiseSVN, e posteriormente a opção Show Log, é possível comparar revisões arbitrárias do arquivo .doc que acabamos de modificar, como no screenshot abaixo:
O que acontecerá? O arquivo será aberto no Microsoft Word, com argumento especial, indicando os dois arquivos a ser comprados, e o Microsoft Word apresentará o http://www.freebsdbrasil.com.br
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil documento com o modo de acompanhar modificações ativo.
Se o documento for de format .odt, o mesmo acontecerá, porém a aplicação que entrará em modo de acompanhamento de modificações será o OpenOffice. Extremamente inteligente, funcional e produtivo.
Agora faremos modificações em outro arquivo binário, um arquivo de imagem. Por exemplo, acompanhe a atualização do logo, e a entrada de log que explica plenamente a motivação dessa atualização.
Pois bem, ao concluir o commit da atualização da logomarca da empresa consultora, vamos voltar a opção Show Log do TortoiseSVN, como no screenshot a seguir.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Em seguida, selecione as revisões que deseja observar as modificações, como no screenshot a seguir. Observe nos detalhes em destaque a seleção das revisões e a opção para comparar essas revisões.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil O TortoiseSVN mais uma vez detectará o tipo de arquivo binário em questão, e apresenta ambos arquivos (de imagem) em um prévisualizador que permite que observamos ladoalado esses arquivos, além de apresentar informações adicionais sobre as características do arquivo.
Se forem arquivos de fotos digitais, apresenta as informações adicionadas pela câmera, em formado jhead, se essas informações existirem. Não é o caso da imagem em questão, então a visualização comparativa será similar ao screenshot abaixo:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Muito prático e simples. O que nos permite perceber que a última modificação nesse arquivo – ou qualquer modificação arbitrária – pode ser considerada um erro. E como restaurar um arquivo errôneamente modificado?
A estratégia é simples, basta reverter uma modificação. Com o processo de reversão você terá localmente uma cópia do arquivo como ele era na revisão em que você escolher. Ou seja, não há qualquer modificação feita na árvore, mas sim apenas localmente.
Para isso, através do navegador de logs que exploramos diversas vezes, escolha a revisão desejada e com o botão da direita, clique em Revert to this revision como no screenshot abaixo.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Como a reversão é apenas local, para efetivar a mudança é necessário o commit. Note que a revisão da árvore será incrementada.
Ou seja a restauração do arquivo é prática, mas o número da revisão nunca é restaurado, garantindo assim um histórico fiel da vida do arquivo desde o primeiro momento que ele foi adicionado ao repositório até o momento atual, da última modificação (revisão) daquele arquivo
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Perfeito, após a conclusão do commit o arquivo estará restaurado no servidor SVN remoto tal como na estrutura local.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Recursos Gráficos e Estatísticos
O TortoiseSVN apresenta ainda alguns recursos gráficos e estatísticos. Por exemplo, a qualquer momento você pode clicar em qualquer trecho da árvore ou de um arquivo com o botão da direita, e obter estatísitcas de acesso à árvore ou ao arquivo. Para isso selecione Show Statistics. Essa estatística inclui datas de modificações e quais usuários trabalham mais em cada trecho do repositório.
Complementarmente, podemos ainda observar um gráfico das principais modificações da árvore, ilustrando a vida do arquivo no repositório. Para isso com o botão da direito, no
submenu TortoiseSVN selecione Revision graph para obter uma visualização gráfica da historia revisional daquele arquivo ou diretório, como nos screenshots que seguem.
Esses recursos são eyecandies em uma primeira impressão, e para desenvolvedores
podem
ser consideradas dispensáveis. Porém, para gerentes de projetos são tão importantes quantos gráficos Gantt ou matrizes de responsabilidade.
Veja abaixo um exemplo simples de apenas um trecho de gráfico revisional para um arquivo com um tempo de vida no repositório Subversion considerado curto:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Quanto maior o tempo de vida do arquivo ou da estrutura da árvore, e maior a vida do próprio repositório, “melhor” esse gráfico tende a ser.
TortoiseSVN em Português Brasileiro
Se realmente desejar usar o TortoiseSVN em português brasileiro, instale o Language Pack que baixamos anteriormente (o dicionário ortográfico é opcional), e a qualquer momento clique com o terceiro botão, escolha o submenu TortoiseSVN, e depois Settings. A tela de configuração do TortoiseSVN será exibida, e na aba Look & Feel escolha a língua portuguesa. Com um pouco de tempo você se acostumará com as novas versões de nome para os comandos Subversion clássicos, com os quais convivemos até o momento.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil PARTE IV RAPIDSVN
Se desejar usar um ambiente gráfico em plataforma Unix, ou em Mac OS X, recomendamos fortemente o uso do RapidSVN. Ele é uma aplicação standalone gráfica, que oferece um frontend cliente ao Subversion. É oficial, mantido pela mesma equipe que desenvolve o Subversion. Sob a Coleção de Ports do FreeBSD está em devel/rapidsvn, e pode ser usada também em Mac OS X além do próprio Windows.
O RapidSVN tem uma característica peculiar adicional. Além de ter como objetivo ser uma aplicação gráfica cliente, RapidSVN tem também intuito de permitir ou facilitar algumas tarefas administrativas, como importação de repositórios. Futuramente a criação de novos repositórios e outros recursos da aplicação svnadmin no ambiente CLI também serão integrados ao RapidSVN.
A vantagem desse ambiente gráfico para Subversion frente outras alternativas, como esavn e kdesvn são o número de recursos, o fato dele ser mantido pelos mesmos autores do próprio Subversion, e não depender de um framework préexistente, como bibliotecas KDE (kdelibs), o que pode não ser um fator desencorajador se você já usa KDE, mas certamente o será se o gerenciador de janelas de escolha for outro, especialmente se a motivação for performance, já que daemons e subsistemas do KDE precisam estar carregados para usar o KDESvn por esemplo.
RapidSVN é desenvolvido com wxWidgets como base para biblioteca gráfica. Originalmente teve o nome de Visual Subversion, projeto que posteriormente foi descontinuado, e o ambiente de desenvolvimento passou a ser continuado pela Tigris, com o nome RapidSVN.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Instalando o RapidSVN
Através da Coleção de Ports do FreeBSD basta entrar em devel/rapidsvn e instalar:
# cd /usr/ports/devel/rapidsvn/
O processo pode ser um pouco demorado, devido as dependências, em especial o wxWidgets. Uma vez instalado, RapidSVN parecerá, em aparência, com uma interface GUI de um cliente FTP, no que tange ao ambiente de trabalho. Porém, bastante distinto em recursos e no trabalho prático.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Fazendo Checkout no RapidSVN
Para fazer Checkout com RapidSVN, abra a aplicação, vá no menu Repository e escolha a opção Checkout. Uma janela adicional solicitará a URL, onde você deve entrar
http://svn.cliente.com.br/svn/<repositório_desejado>
No caso de nossos exemplos, http://svn.cliente.com.br/svn/projeto01. Também será solicitado onde é o diretório local, caminho para a sincronia com o repositório remoto. Como já discutimos, use o ~/svn_root/. Portanto entre combinados
/usr/home/seu_usuario/svn_root
Opcionalmente você pode sincronizar apenas com uma revisão arbitráriamente, ao invés da mais recente, e desabilitar a opção de Checkout recursivo. Nesse caso o checkout será apenas da estrutura raiz.
Todas as outras operações (commit, revert, update, add) ficam no menu Modify. As opções de comparação e Diff ficam no menu Query. O restante do trabalho é muito intuitivo, e pode ser desempenhado naturalmente, com base no que já estudamos anteriormente.
Uma das grandes vantagens do RapidSVN é poder trabalhar com múltiplas janelas simultâneamente, no mesmo repositório. Ambiente típico de Mac OS onde cada ação fica em pequenas janelas independentes ao invés de tudo ser parte de um ambiente só.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil RapidSVN também tem recurso de Gráficos Revisionais. Para ativálos você pode escolher uma determinada estrutura da árvore Subversion ou um arquivo, e mandar gerar o gráfico revisional através do menu Extras.
Uma grande vantagem do gráfico revisional do RapidSVN sobre o TortoiseSVN por exemplo é o fato dele permitir visualização do gráfico integral, em thumb, e explorar detalhes apenas de um trecho do gráfico, como observamos no exemplo abaixo:
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Agora que você conhece a ferramenta, basta começar usar e gerenciar seu projeto pelo RapidSVN.
Observações Finais
É importante ilustrar que apenas as ações mais frequentes do ambiente Subversion foram estudadas ao longo desse documento. As outras opções devem ser experimentadas em ambiente real, com base na documentação indicada. E lembrese que o conceito é exatamente o mesmo, esteja você usando o svn CLI, o TortoiseSVN ou qualquer outro frontend gráfico para o Subversion.
Uma última consideração: leia o manual do Subversion indicado, especialmente a parte conceitual sobre a organização do repositrio em ramos (branches) e marcações (tags), e organize seu repositório com base nesses conceitos sempre que possível. Serão fundamentais para a organização estrutura da árvore Subversion.
Esse documento aborda o TortoiseSVN pois de forma geral um ambiente de produção com Windows tem índice proveitoso de melhoria de produtividade usando essa ferramenta, e porquê todo o poder de um ambiente de revisionamento e controle de versões concorrentes pode ser especialmente útil para um ambiente Windows. Enquanto em ambiente Unix temos as aplicações de linha de comando, no Windows usar CLI apesar de possível é menos trivial, e os usuários dessa plataforma tendem a desistir da solução se o ambiente CLI for o único disponível.
eSvn é uma alternativa GUI ao RapidSVN e TortoiseSVN, disponível para múltiplas arquiteturas, porém não abordamos pois seus recursos são redundantes com do RapidSVN.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Leitura Recomendada
Existe um sistema de versionamento concorrente que utiliza o Subversion como framework base, porém com conceitos e objetivos ou tanto quanto diferentes. Tratase do SVK.
O SVK é um VCS decentralizado, que permite que um ambiente de versionamento concorrente exista simultâneamente em múltiplos servidores Subversion, independentes, mas que periodicamente se sincronizam.
A idéia essencial do SVK é a possibilidade de trabalhar com mirroring (espelhamento) de repositórios SVN, permitindo ter localmente um repositório sincronizado com múltiplos outros. Isso permite o trabalho desconectado (offline) sem deixar de desempenhar commits ou modificações no repositório. Periodicamente esses repositórios são sincronizados, quando online. O sistema de versionamento segue um padrão próprio, chamado SVK Revision System, para permitir revisionamento decentralizado sem conflitos.
É basicamente apenas uma abordagem diferenciada, com a real (e provavelmente única) vantagem de permitir trabalho offline e integração automatizada de múltiplos repositórios espelho. Depende drásticamente do Subversion, e pode (experimentalmente) integrar repositórios SVN e CVS. Muitos consideram a abordagem complexa demais, e com poucas vantagens já que o próprio Subversion pode ser espelhado com processos tradicionais, e a possibilidade de operações desconectadas hoje em dia não é mais vantagem considerada, tendo em vista baixo custo e popularização de conexões dedicadas de banda larga.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Porém, se você gosta de tratar um assunto à níveis extremos, conhecer e ter experiência com o SVK é de fato uma dessas etapas, no que tange a teoria, arquitetura e implementação de servidores de versionamento concorrente decentralizado.
Portanto o manual oficial do SVK:
http://svkbook.elixus.org/nightly/en/index.html
É leitura recomendada para momentos de descontração. É pouco provável que você tenha necessidades reais de usar um ambiente como o SVK, mas vale pela curiosidade. Porém, se precisar do SVK, o mais importante você já aprendeu: o Subversion – framework primário usado pelo SVK.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Conclusão
Ao longo desse artigo, divido em três partes, aprendemos a criar o mais completo ambiente para versionamento concorrente e paralelo de Software, usando para isso o Subversion, mais poderoso sistema aberto desse tipo, e certamente um dos mais completos, estáveis e rápidos dentre todas as opções no mercado, sejam livres ou proprietárias. Integramos o Subversion com um servidor Web como nenhum outro sistema de versionamento permite.
Com o TRAC criamos um ambiente completo de documentação, manutenção e acompanhamento da vida do projeto, completamente extensível e integrado ao Subversion.
Por último discutimos o uso de ferramentas gráficas que permitem a usuários Windows ou usuários de outras plataformas sem intimidade com o ambiente de linha de comando a tirar total proveito desse ambiente de versionamento de software e projetos, sem qualquer limitação, em um ambiente intuitivo e integrado.
Se você tem um ambiente de produção, seja o objeto a ser produzido qual for, de documentos de texto, projetos PMI, software, à imagens e vídeos, o uso de um sistema de versionamento traz organização, padronização, controle e principalmente, segurança à seu ambiente de trabalho, além de oferecer a adoção flexível de uma metodologia inteligente e prática. E com essas ferramentas você tem o mais completo ambiente com esse propósito, não possível com outras soluções comerciais ou alternativas livres.
Artigo publicado em 30/04/2007 Área Corporativa FreeBSD Brasil Referências e Sugestões de Leitura
As referências em itálico são de leitura obrigatória para adequada compreensão e adoção de conceitos de sistema de versão concorrente com Subversion.
http://svnbook.redbean.com/nightly/pt_BR/svn.intro.architecture.html
http://svnbook.redbean.com/nightly/pt_BR/svn.intro.features.html
http://svnbook.redbean.com/nightly/pt_BR/svn.basic.repository.html
http://svnbook.redbean.com/nightly/pt_BR/svn.basic.vsnmodels.html
http://svnbook.redbean.com/nightly/pt_BR/svn.basic.inaction.html
http://subversion.tigris.org/faq.html
http://svnbook.redbean.com/nightly/pt_BR/
http://subversion.tigris.org/tools_contrib.html
http://www.szabgab.com/subversion_vs_xyz.html
http://trac.edgewall.org/wiki/TracGuide
http://trac.edgewall.org/wiki/TracFaq
Leitura complementar:
http://svkbook.elixus.org/nightly/en/index.html

Versionamento Concorrente Completo com Subversion

Transcrição

Documentos relacionados

Rafaelle Magella de Santiago - PMI-CE

Slides de Apresentação

sinopse “quem quer ser milionário

gameboy advancetm introdução editores testes o jogo

The life and times of Coretta Scott King

CONCURSO “A abóbora mais original!” (escultura criativa)

Softwares: Tortoise SVN Crucible JIRA

- Você Faz o Design, Nós Executamos!

Como fazer a Análise de Mercado

Ofensa Propter Officium e Legit