Tutorial – Usuário Subversion

Standard

Prefácio

Lancei este tutorial sobre o Subversion, originalmente, no dia 30 de maio de 2005 ainda pelo PATUX – Projeto de Aprendizado Tecnológico Universitário, na Universidade de Brasília (UnB), a partir de traduções e adaptações do manual oficial do mesmo (http://svnbook.red-bean.com). Tinha como objetivo explicar o funcionamento deste sistema de versionamento (com documentação deficitária, em português, à época), e ensinar os membros do projeto a acessar os repositórios e contribuir para o desenvolvimento de software livre.

Desde então, muita coisa mudou: o projeto terminou, o Subversion (que na período estava na versão 1.0.8 e era visto com certa desconfiança em relação ao já estabelecido CVS) já chegou à versão 1.5.4, vários novos front-ends foram lançados, suporte às mais populares IDEs (Eclipse, Visual Studio, entre outras) foi adicionado e, não menos importante (pelo menos para mim :P), pude alcançar um sonho particular: trabalhar e liderar conjuntamente uma empresa que verdadeiramente representa e trabalha em prol do software livre, a PWSys – Soluções em Tecnologia.

Assim sendo, creio ser de grande valia o relançamento deste documento, revisado e generalizado para utilização em cenários menos específicos que os que imaginei inicialmente. Reforça, ainda, a posição de comprometimento da PWSys com relação ao software livre e sua comunidade: outros documentos como este serão lançados, estando dispostos para auxiliar a propagação da cultura open source no Brasil.

Dito isso, sigam com o prefácio original deste tutorial.

Este tutorial visa dar uma introdução rápida sobre como utilizar o sistema de controle de versões Subversion. Este tutorial consistirá basicamente de quatro capítulos (clique nos links para ir diretamente):

  1. O que é o Subversion?
  2. Conceitos básicos de versionamento
  3. Comandos do Subversion
  4. Front-ends
Espero que com o que for explicado aqui o leitor possa utilizar de pronto e sem maiores problemas qualquer repositório Subversion. Esta é uma leitura altamente recomendada para os iniciantes em sistemas de versionamento, porém se quiser obter mais informações consulte o site oficial do Subversion (http://subversion.tigris.org) e o manual oficial (http://svnbook.red-bean.com), que contém muito mais detalhes do que este documento. Quaisquer dúvidas ou sugestões busque diretamente o autor, em seu e-mail (
<!–
var prefix = ‘ma’ + ‘il’ + ‘to’;
var path = ‘hr’ + ‘ef’ + ‘=’;
var addy72051 = ‘fbscarel’ + ‘@’;
addy72051 = addy72051 + ‘pwsys’ + ‘.’ + ‘com’ + ‘.’ + ‘br’;
document.write( ‘<a ‘ + path + ‘\” + prefix + ‘:’ + addy72051 + ‘\’>’ );
document.write( addy72051 );
document.write( ‘<\/a>’ );
//–>\n fbscarel@pwsys.com.br
<!–
document.write( ‘<span style=\’display: none;\’>’ );
//–>
Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo.
<!–
document.write( ‘</’ );
document.write( ‘span>’ );
//–>
). Boa leitura!

Felipe Scarel, 10 de dezembro de 2008.

Licença

Copyright (c)  2008  Felipe Brant Scarel e PWSys – Soluções em Tecnologia
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be read at http://www.gnu.org/copyleft/fdl.html

Histórico de Revisões

Versão Data Autor Comentários
1.1 2008-12-10 11:25:26 Felipe Scarel Novo prefácio, Reescrita do Cap. 4
1.0 2005-05-30 01:30:04 Felipe Scarel Versão inicial do documento

O que é o Subversion?

O Subversion é um sistema de controle de versões livre, ou opensource. Com “sistema de controle de versões” queremos dizer que ele é capaz de gerenciar arquivos e diretórios ao longo do tempo. Basicamente, os arquivos são guardados em um repositório central e são servidos aos clientes. Muito embora isto se assemelhe a um servidor de arquivos, a diferença fundamental do Subversion é que ele guarda todas as modificações feitas nos arquivos e diretórios ao longo do tempo. Isso nos permite recuperar versões antigas dos dados ou simplesmente verificar o histórico destes. Por este motivo, é comum pensar nos sistemas de versionamento como “máquinas do tempo”. Para compreender melhor o Subversion é interessante que conheçamos um pouco da sua história:

No mundo do software livre, desde o início fez-se necessária uma ferramenta que pudesse controlar o aparente “caos” com que os programas são desenvolvidos. Para que todos pudessem desenvolver simultaneamente e sem prejuízo à organização foram criadas ferramentas de versionamento livres, sendo a mais bem-sucedida delas o Concurrent Versioning System (CVS), que logo se tornou o padrão em projetos opensource, e assim permanece até hoje. E com toda a razão, pois o fato de ser software livre, ter um design não-restritivo e bom suporte a rede permitem que vários programadores ao redor do mundo compartilhem seu código e construam softwares em conjunto. Porém, dada a sua idade, o CVS está se tornando ultrapassado, e muitos recursos modernos dos sistemas de versionamento não podem nele ser encontrados.

No início de 2000, a CollabNet (http://www.collab.net) comecou a buscar programadores para desenvolver um substituto ao CVS, que pudesse implementar o que ele apresenta de melhor mas sem copiar suas falhas mais evidentes. Eles então buscaram Karl Fogel (também um dos autores do livro do Subversion), que já vinha discutindo idéias semelhantes com seu amigo Jim Blandy. Este último inclusive já havia tido não apenas a idéia do nome “Subversion” bem como feito o layout básico de um repositório Subversion. Chamado pela CollabNet, Karl imediatamente foi trabalhar no projeto e Jim fez com que sua companhia, a conhecida Red Hat, praticamente o doasse ao projeto. Fortalecidos ainda pela contratação de Ben Collins-Sussman, eles iniciaram a codificação, e, após catorze meses, mais precisamente a 31 de Agosto de 2001, o Subversion passou a versionar seu próprio código e tornou-se uma realidade.

Muito embora os sistemas de versionamento, e por conseguinte o Subversion, sejam mais comumente usados para auxiliar programadores em seu desenvolvimento, é importate frisar que o Subversion não é limitado a ajudar programadores e pode ser utilizado para versionar qualquer tipo de dado. Para esclarecer os conceitos por trás dos sistemas de versionamento leia o próximo capítulo, que tratará precisamente deste tema. Se já estiver acostumado com estes conceitos e quiser apenas ver como o Subversion os implementa, pode seguir diretamente para o capítulo 3. Caso queira começar realmente rápido, mas provavelmente sem uma base teórica necessária, siga para o capítulo 4.

Conceitos Básicos de Versionamento

O Subversion é um sistema centralizado para compartilhar informações e dados. Ele é baseado em um repositório central, onde os dados ficam guardados sob a forma típica de uma árvore de arquivos e diretórios. Um número qualquer de clientes conectam-se ao repositório e lêem (recebendo as informações dos outros) ou escrevem (disponibilizando a informação aos demais) nestes dados. Até o momento isto não seria muito diferente de um servidor de arquivos normal, mas como foi explicado no primeiro capítulo, o Subversion tem a capacidade de guardar todas as alterações feitas aos arquivos, permitindo que elas sejam observadas, comparadas entre si, e eventualmente sobrescritas umas sobre as outras.

Já sabemos o principal objetivo dos sistemas de versionamento. Porém, como faríamos para que todos pudessem trabalhar colaborativamente mas sem que ocorresse uma eventual sobrescrita, acidental, em nosso repositório? Vamos primeiramente apresentar o problema:

  • Suponhamos que dois usuários leiam as informações do repositório e iniciem a fazer modificações para posteriormente submeter suas contribuições. Se um usuário mandar suas modificações, e, logo depois, o outro também tiver a mesma idéia, o que ocorrerá é que as modificações do primeiro usuário não serão visualizadas ou aproveitadas, pois serão substituídas pelas alterações do segundo (uma vez que o padrão é visualizar a versão mais recente).

Para este problema temos duas soluções que são largamente utilizadas pelos sistemas de versionamento: a “Lock-Modify-Unlock” (Trancar-Modificar-Destrancar) e a “Copy-Modify-Merge” (Copiar-Modificar-Unir). Vamos apresentar separadamente cada uma delas:

  • “Lock-Modify-Unlock”:

Muitos sistemas de versionamento utilizam esta solução, que consiste basicamente em um sistema  parecido com o aluguel de livros em uma biblioteca: um usuário tranca o arquivo para edição, e enquanto ele faz suas modificações os demais não podem acessar o arquivo para escrita; se tentarem fazê-lo, o servidor irá negar a requisição. Logo após o primeiro usuário encerrar sua edição, ele irá destrancar o arquivo, e agora sim os demais poderão acessá-lo. Os problemas desta solução logo aparecem, pois ela é muito restritiva: se o primeiro usuário, por exemplo, sair de férias e esquecer o arquivo trancado, os demais terão que esperar até que ele volte ou contatar um administrador do sistema, o que não é desejável. Outro fator: suponhamos que dois usuário queiram editar o mesmo arquivo; isto não será um problema se um deles quiser editar o começo do arquivo e o outro quiser editar o final deste, e neste caso a solução tornaria o processo burocrático. Finalmente, esta solução cria um falso senso de segurança, pois se dois usuários trancarem arquivos diferentes, porém dependentes entre si, eles poderão modificá-los de forma a torná-los incompatíveis. Neste caso o sistema não teve poder para impedir que tal fato prejudicial ocorresse.

  • “Copy-Modify-Merge”:
O Subversion, CVS, e outros sistemas de versionamento preferem utilizar esta solução como uma alternativa ao trancamento dos arquivos. Neste modelo, cada usuário contata o repositório e copia para si a chamada “working copy”, que é uma cópia fiel da estrutura de arquivos e diretórios do servidor. Esses usuários trabalham em suas cópias particulares em paralelo, e finalmente suas modificações são unidas em uma versão final. Na maioria das vezes o repositório cuida do trabalho de fazer a união ocorrer corretamente, mas em última instância um ser humano deve cuidar desse processo. Na prática, suponhamos que dois usuários obtivessem working copies para si e comecassem a editá-las. Se um deles submeter suas modificações primeiro, quando o outro tentar mandar suas alterações o repositório lhe retornará um erro de “out-of-date” (arquivo antigo). Neste caso, o usuário receberá uma cópia do arquivo novo e deverá comparar esta nova versão com a sua, alterada localmente. Há uma boa chance de que as modificações não sejam conflitantes, e ele então poderá unir suas modificações com as de seu colaborador e submeter uma nova versão, com ambas as contribuições. Mas e se as alterações forem conflitantes? Como o próprio nome indica, nesse caso temos um “conflict” (conflito), e este deverá ser resolvido pelo usuário (uma vez que o programa não é capaz de tomar as decisões inteligentemente). Após resolver o conflito preexistente, possivelmente após uma conversa com o outro usuário, ele poderá então mandar a versão final e funcional.

O modelo utilizado pelo Subversion pode parecer caótico, mas quando vamos observá-lo mais de perto veremos que ele funciona de forma transparente; conflitos são infrequentes, e, quando ocorrem, são resolvidos rapidamente. Isso depende, contudo, de uma comunidade comunicativa e responsiva.

Comandos do Subversion

Vamos ver agora o Subversion em ação. Utilizaremos nos exemplos o cliente de linha de comando do Subversion, “svn”. No quarto capítulo apresentarei ainda alguns clientes gráficos do Subversion para poupar aqueles de vocês que não apreciam a interface de texto.

Primeiramente, suponhamos que iremos acessar um repositório exemplo. Vamos cuidar então da primeira parte, que será obter nossa working copy. Talvez fosse uma boa idéia ver a estrutura de diretórios do repositório exemplo na web, através de um visualizador como o WebSVN; digamos que a estrutura dos diretórios no servidor fosse a seguinte:

svn/
.
. exemplo/
. tags/
. branches/
. trunk/
. README
.
. outros/
. x/
. y/
. z/

Vamos começar então com o comando mais importante de todos – como obter ajuda:

[shell]$ svn help

O comando acima mostraria todos os complementos possíveis ao “svn”, e poderíamos então descobrir qual comando é o mais apropriado para o nosso problema. Supondo agora que gostaríamos de obter uma working copy do repositório exemplo, digitaríamos então o seguinte comando:

[shell]$ svn checkout http://www.foo.bar/svn/exemplo
A  exemplo
A  exemplo/tags
A  exemplo/branches
A  exemplo/trunk
A  exemplo/trunk/README
Checked out revision 1.

Este comando faria o checkout, ou cópia, da pasta “exemplo”, com todo o seu conteúdo, para o diretório atual. Isto quer dizer que, com este comando, obteríamos uma working copy para edição local, possibilitando-nos que trabalhássemos nela de pronto.

Podemos observar naquela última linha “Checked out revision 1”; vejamos o que ela exatamente quer nos dizer: ela nos informa que acabamos de fazer o checkout (ou cópia) dos arquivos do servidor pertencentes à revisão 1. Quando dizemos “revisão 1”, estamos nos referindo ao estado exato do repositório quando este se encontrava na referida revisão 1. Após alguém mandar alterações ao repositório, este passará à revisão 2, que será a mais recente (também conhecida como HEAD). Mas a revisão 1 ainda estará lá, e podemos vê-la ou recuperá-la com os comandos nativos do subversion, normalmente adicionando o switch “-r” ou “–revision”.

Podemos nos referir às revisões de três formas: a mais comum é através do número, que é único e crescente (como em “revision 1”); outra forma é através de palavras-chave que o Subversion nos fornece, como por exemplo HEAD (que se refere à revisão mais recente no repositório); finalmente, podemos nos utilizar ainda de datas em formatos predefinidos.

Expliquemos ainda a estrutura de diretórios dividida em trunk/, branches/ e tags/, largamente utilizada como padrão em repositórios: o diretório trunk/ contém a linha principal de desenvolvimento do projeto, e é nela que boa parte do código é desenvolvido. Pode ser necessário, no entanto, que se desenvolva uma nova capacidade ou característica de um programa, por exemplo. Tal desenvolvimento potencialmente tornaria o código da linha trunk/ instável, e, para evitar esse fato criaríamos um branch do projeto, focado unicamente em desenvolver essa característica específica que seria posteriormente portada de volta à árvore trunk/. Esta é superficialmente a função do diretório branches/.

É também perfeitamente possível que um programa, documento, etc, chegue em um nível de estabilidade tal que poderia ser liberado ao público e no qual não seria desejável nenhuma alteração. Essa é a função do diretório tags/, no qual residem as denominadas versões “estáveis” do projeto em questão.

Retornando aos comandos do Subversion, suponhamos agora que você deixou sua working copy parada por uns tempos e agora resolveu voltar a trabalhar nela. É possível, na verdade provável, que o estado do repositório tenha sido alterado desde sua última conexão. Para trabalhar em cima das versões mais recentes, é necessário que baixemos as modificações, e o faremos através do svn update:

[shell]$ svn update
U  exemplo/trunk/README
U  exemplo/trunk/novo.txt
Updated to revision 2.

Este comando deverá ser executado sob o diretório em que se encontra a working copy, obviamente. Ele irá buscar no servidor as modificações ocorridas em relação à versão local e aplicá-las de imediato.

A esta altura você deve ter notado as letras que apareceram nos últimos comando, A e U. Mas o que elas querem dizer? Vamos ver a seguir:

  • U: o arquivo foi “Updated” (atualizado) a partir do servidor
  • A: o arquivo ou diretório foi “Added” (adicionado) à sua working copy
  • D: o arquivo ou diretório foi “Deleted” (deletado) da sua working copy
  • R: o arquivo ou diretório foi “Replaced” (substituído) em sua working copy, ou seja, um elemento foi deletado e posteriormente outro com o mesmo nome foi adicionado; embora tenham o mesmo nome o repositório consegue percebê-los como arquivos diferentes
  • G: o arquivo no servidor recebeu alterações, mas sua cópia local tinha as suas modificações; ou as alterações não interceptavam ou eram idênticas às suas, então o Subversion conseguiu colocá-las em  estado de “merGed” (união) sem problemas
  • C: o arquivo recebeu alterações “Conflicting” (conflitantes) com as suas, ou seja, na mesma seção do arquivo; trataremos deste caso mais adiante no capítulo

Agora que já temos nossa working copy, podemos começar a trabalhar nela. Temos a possibilidade de fazer dois tipos de mudança: em arquivos específicos ou em diretórios (adicionando e removendo arquivos, por exemplo). No primeiro caso, não é necessário informar o Subversion com algum comando específico, pois ele será capaz de perceber quais arquivos foram mudados e submeter essas alterações ao servidor. Já no segundo caso, poderemos usar um dos quatro comandos básicos para manipulação de arquivos, explicados abaixo:

  • svn add

[shell]$ svn add novo.txt
A novo.txt

Este comando irá adicionar o arquivo “novo.txt” ao sistema de controle de versões, e ele também passará a ser versionado pelo repositório Subversion. Isto quer dizer que o arquivo existia para o seu computador mas era ignorado pelo Subversion, e, ao usar o “svn add”, você informou o Subversion que ele deve agora ser versionado. Se fosse um diretório, ele e todos os seus arquivos subjacentes seriam também adicionados. Vale lembrar que este passo não é opcional: não basta criar o arquivo, o “svn add” é fundamental.

  • svn delete

[shell]$ svn delete novo.txt
D novo.txt

Este outro comando irá agendar “novo.txt” para deleção do repositório. Se este fosse um arquivo ou link simbólico, ele seria imediatamente deletado da sua working copy; se fosse um diretório, seria deletado apenas após mandarmos as alterações ao servidor. É importante frisar que, após mandarmos as mudanças de volta ao repositório, o arquivo será deletado apenas da revisão mais recente, mas ainda estará presente nas revisões anteriores.

  • svn copy

[shell]$ svn copy novo.txt velho.txt
A velho.txt

O “svn copy” acima irá copiar o arquivo “novo.txt”, juntamente com seu histórico, para um arquivo denominado “velho.txt”, que será imediatamente agendade para adição no repositório. O histórico do arquivo criado irá indicar que ele é proveniente de um outro.

  • svn move

[shell]$ svn move novo.txt velho.txt
A velho.txt
D novo.txt

Como pode ser visto acima, o “svn move” irá apenas fazer o papel de “svn copy” e “svn delete” em um só comando; ele irá copiar o arquivo com um outro nome e depois irá deletar o original, o que seria basicamente o equivalente a renomear um arquivo qualquer.

Agora que já editamos o que fosse necessário ou desejável, seria interessante verificar o que foi modificado antes de mandar nossas alterações ao repositório, criando uma nova revisão. Podemos fazê-lo através do svn status (certamente o comando que você deve, espera-se, mais utilizar no Subversion):

[shell]$ svn status
M      bar.c
?      foo.o
!      qq_dir
I      .screenrc
A  +   moved_dir
M  +   moved_dir/README
D      outros/teste.c
A      outros/calc/soma.h
C      outros/calc/divide.c
R      xyz.c
S  outros/game

Temos acima um possível exemplo de saída do comando “svn status”, que nos ajudará a explicar os status mais importantes a serem compreendidos. Na primeira coluna, temos:

  • A: o arquivo/diretório foi agendado para adição no repositório
  • C: o arquivo está em estado de conflito e será necessário resolvê-lo antes de mandar as alterações ao servidor
  • D: o arquivo/diretório foi agendado para deleção no repositório
  • M: o conteúdo do arquivo foi modificado
  • R: o arquivo foi agendado para substituição no repositório, com o mesmo nome de um que foi deletado
  • ?: o arquivo em questão não está sob controle de versão (possivelmente foi criado e não foi utilizado o “svn add”)
  • !: o arquivo não está presente por algum motivo, possivelmente tendo sido deletado sem o uso de um comando Subversion
  • I: o arquivo foi configurado para ser ignorado pelo sistema de controle de versões;

Na coluna seguinte poderemos ver um “+” ou não, indicando que um arquivo foi agendado para adição no repositório com a preservação de seu histórico. Isso provavelmente nos dirá que ele é proveniente de uma cópia com o “svn copy” (A+), ou, além de ter sido copiado também foi modificado localmente (M+). A última coluna nos dirá se um arquivo ou diretório foi deslocado do caminho do restante de sua working copy, com o comando “svn switch”, para um branch ou tag (explicados mais à frente). Para a referência completa dos possíveis outputs do “svn status” consulte o manual oficial do Subversion.

Adicionando o switch “-u” ou “–show-updates” ao “svn status”, juntamente com a opção “-v” ou “–verbose” (para maior detalhamento), ele irá contatar o servidor e comparar suas modificações com as revisões que lá se encontram, e irá informar sobre arquivos antigos (out-of-date):

[shell]$ svn status –show-updates –verbose
M      *        44        23    john      README
M               44        20    david     bar.c
*        44        35    susan     outros/teste.c
Status against revision:   46

Os asteriscos acima nos indicam que caso fosse utilizado o “svn update” neste ponto os arquivos “README” e “teste.c” receberiam modificações. Isto quer dizer que nossa revisão local está desatualizada e devemos fazer um update para receber as modificações nestes arquivos e conferir se estas conflitam com a versão local.

Digamos agora que queremos saber exatamente quais modificações fizemos aos arquivos antes de mandá-las ao servidor; esta seria uma boa hora para usar o svn diff, que mostrará as diferenças entre a nossa versão modificada e a versão obtida inicialmente (que fica no diretório oculto .svn):

[shell]$ svn diff
Index: teste.c
===================================================================
— teste.c (revision 3)
+++ teste.c (working copy)
@@ -1,7 +1,12 @@
+#include
+#include
+#include
+
+#include

int main(void) {
–  printf(“Ola mundo\n”);
+  printf(“Ola de novo mundo\n”);
return 0;
}

As modificações são mostradas em formato diff unificado, sendo as linhas adicionadas mostradas com um “+” antes e as deletadas mostradas com um “-“. É interessante notar que podemos facilmente produzir um patch (arquivo incluido apenas as modificações em um arquivo) com o auxílio do svn diff, como no exemplo abaixo:

[shell]$ svn diff > patchfile

Suponhamos então que você descobrisse que as suas alterações ao “teste.c” acima foram feitas por engano, e que portanto você gostaria de retornar este arquivo ao seu estado original; é um bom momento para utilizar o svn revert:

$ svn revert teste.c
Reverted ‘teste.c’

Isto retornará nosso arquivo “teste.c” ao seu estado original, quando fizemos nosso último checkout a partir do repositório. É um processo semelhante ao utilizado para recuperar eventuais modificações mandadas ao servidor mas que foram desastrosas.

Neste último caso, bastaria dar um checkout em uma revisão anterior e funcional (usando o switch “–revision”), e posteriormente mandar esta revisão correta ao servidor novamente, se tornando HEAD.

Vale lembrar ainda que estes trás últimos comandos, muito embora lidem diretamente com os arquivos antigos, dispensam uma conexão com a rede, pois o Subversion inteligentemente mantém uma cópia imodificada dos arquivo em uma pasta oculta “.svn”, e depois apenas compara o conteúdo desta pasta com as modificações feitas pelo usuário.

Já estamos praticamente finalizados com nossa tarefa diária: sabemos adicionar e deletar arquivos, verificar as modificações feitas, conferir se estas estão desatualizadas e resolver conflitos simples, processo automatizado pelo Subversion. Mas ainda resta uma dúvida: e se nossas modificações não resultarem em um conflito simples, no qual nossa alteração intercepta diretamente a de um colaborador? Vejamos a saída de um svn update que causará esse problema:

[shell]$ svn update
U  INSTALL
G  README
C  teste.c
Updated to revision 46.

As letras U e G caem naqueles casos estudados anteriormente: no primeiro foi feito um update simples e no segundo o Subversion conseguiu unir as modificações locais e remotas sem maiores problemas. Já a terceira ocorrência poderá nos causar um problema, pois indica um conflito (C). Neste caso surgirão três arquivos no diretório de trabalho: [ARQUIVO].mine (com as alterações locais), [ARQUIVO].r[OLD] (arquivo imodificado desde o último update) e [ARQUIVO].r[NEW] (o arquivo proveniente do update, diretamente do repositório). Serão ainda colocados marcadores de conflito no arquivo original, a fim de auxiliar o processo de análise. Poderemos resolver o conflito de três formas:

  • Unir os arquivos manualmente:

Pode parecer ameaçador, mas fazer a união dos arquivos é na verdade realmente simples: analisar-se-á as alterações feitas remotamente e estas serão comparadas às locais. O usuário deverá decidir qual delas é a melhor, ou então poderá juntar ambas as soluções. De qualquer maneira, é imprescindível que haja uma boa comunicação entre os colaboradores, pois seria conveniente que houvesse uma discussão entre eles para decidir o melhor caminho.

  • Escolher uma das opções:

Pode-se ainda optar por simplesmente copiar uma das soluções inteiramente, ou a local ou a remota. Nesse caso, bastaria um “cp” simples dos sistemas UNIX-like para resolver o conflito.

  • Descartar as edições locais:

Finalmente, é também possível perceber que as alterações feitas localmente não deveriam ser mandadas ao repositório. Neste último caso, bastaria um “svn revert” para encerrar o conflito e retornar os arquivos aos seus estados originais.

Uma vez resolvidos todos os conflitos, devemos informar o Subversion, e o faremos com o comando svn resolved:

[shell]$ svn resolved teste.c

Com este comando os arquivos extras que haviam sido criados serão excluídos e a condição de conflito desaparecerá. Agora sim poderemos mandar nossas modificações ao repositório (finalmente!), e o faremos com o comando svn commit:

[shell]$ svn commit -m “Algumas modificacoes simples no arquivo teste.c”
Sending        teste.c
Transmitting file data .
Committed revision 47.

O comando acima submeterá nossas modificações locais ao repositório, e a mensagem passada através do switch “–message” ou “-m” será a mensagem de log do commit. É importantíssimo que essa mensagem descreva precisamente o que foi modificado, assim ficará muito mais fácil recuperar o repositório após um engano, além de ajudar os usuário a utilizar o sistema com mais eficiência. Essa mensagem pode ser ainda passada através de um arquivo, com o switch “–file”.

Existem ainda muitos outros comandos que este tutorial não cobriu, afinal o seu foco é de que seja uma fonte rápida para consulta e aprendizado. Dentre estes encontram-se comandos de pesquisa e administrativos. É altamente recomendada a leitura, complementar, do manual oficial do Subversion.

Front-ends

Desde a versão original deste documento, o número de front-ends disponíveis para o Subversion aumentou drasticamente, exigindo total reformulação desta seção. Aos programas descritos originalmente (RapidSVN, WebSVN e TortoiseSVN), juntaram-se vários outros dignos de nota e de usos variados, e que tornam esse sistema de controle de versão ainda mais interessante de ser utilizado. De clientes stand-alone até aqueles integrados ao desktop, passando por aplicações para browsing via web ou IDE, o número de opções para acessar e operar repositórios SVN é tanto que seria até injusto eleger alguns poucos para figurar neste tutorial.

Assim sendo, irei utilizar o mesmo approach da página de links do site oficial do Subversion (http://subversion.tigris.org/links.html): por categorias, cada aplicação e um link para sua página será apresentado, bem como uma breve descrição do programa. Sem mais delongas, vamos à lista:

  1. Cornerstone: cliente gráfico Subversion para Mac OS X. Não é open source, mas possui versão trial gratuita disponível
  2. eSvn: cliente gráfico multiplataforma baseado em QT para o Subversion
  3. FSVS: rápido cliente de linha de comando para o Subversion centrado em implantação de software
  4. KDESvn: cliente Subeversion para o KDE
  5. QSvn: cliente gráfico multiplataforma para o Subversion
  6. RapidSVN: cliente gráfico multiplataforma para o Subversion
  7. RSVN: script Python que permite múltiplas operações de repositório em uma única transação atômica
  8. SmartSVN: cliente gráfico multiplataforma para o Subversion. Não é open source, mas está disponível em versões gratuita e comercial
  9. Subcommander: cliente gráfico multiplataforma para o Subversion, inclui ferramenta para merge textual
  10. SvnX: cliente gráfico multiplataforma para Mac OS X Panther
  11. Syncro SVN Client: cliente gráfico multiplataforma para o Subversion. Não é open source, mas possui versão trial disponível para Mac OS X, Windows e Linux
  12. WorkBench: ambiente de desenvolvimento multiplataforma utilizando Subversion, escrito em Python
  13. Versions: cliente gráfico Subversion para Mac OS X. Não é open source; requer licença comercial
  14. ZigVersion: interface Subversion para Mac OS X. Interface voltada a workflows típicos de programadores. Não é open source
  1. Cascade: driver de sistema de arquivos multiplataforma para o Subversion, tanto gráfico quanto em linha de comando. Também provê outras funcionalidades de alto nível. Não é open source; gratuito para uso pessoal
  2. KSvn: cliente Subversion para o KDE; um plugin para o Konqueror
  3. SCPlugin: integração Subversion para o Finder do Mac OS X
  4. TortoiseSVN: um cliente Subversion, implementado como extensão do shell do Windows
  • Plugins para IDEs (vale lembrar que muitas IDEs suportam o Subversion nativamente ou por plugins inclusos; esta seção lista os plugins não-inclusos com as IDEs)
  1. Aigenta Unified SCC: plugin Subversion/CVS para programas compatíveis com MSSCCI, incluindo o Microsoft Visual Studio e outros. Não é open source, mas possui versão trial gratuita disponível
  2. AnkhSVN: integração Subversion para o Microsoft Visual Studio
  3. CW Subversion: plugin VCS para o Metrowerks CodeWarrior
  4. Subclipse: plugin Subversion para o Eclipse
  5. Subversive: plugin Subversion para o Eclipse
  6. SVN SCC Proxy: plugin SCC para SVN. Este não é um projeto open source
  7. VisualSVN: integração Subversion para o Visual Studio .NET 2003, 2005 & 2008. Este é um produto comercial de código fechado
  8. WLW-SVN: extensão Subversion para o WebLogic Workshop (8.1.3/8.1.4)
  1. psvn.el: interface Subversion para o emacs
  2. Vcscommand.vim: plugin de integração CVS/SVN/SVK para o editor vim
  1. Trac: o Trac é um sistema web minimalista para gerenciamento de projetos e tracking de bugs e requisições. Ele provê uma interface ao sistema de controle de versões (Subversion), um Wiki integrado e funcionalidades de report
  2. Collaboa: browser de repositório e tracker de requisições, similar ao Trac
  1. SVN::Web
  2. ViewVC (previamente conhecido como ViewCVS)
  3. WebSVN
  4. Insurrection: Repositório em http://svn.sinz.com/svn/Insurrection/
  5. Chora
  6. SVN::RaWeb::Light
  7. FlexySvn
  8. perl_svn
  9. mod_svn_view
  10. bsSvnBrowser
  11. sventon
  12. WebClient for SVN

Conclusão

Espero que este documento tenha sido de ajuda para o seu aprendizado, leitor, e através dele estou certo de que foi possível aprender os passos fundamentais para um dia de trabalho completo em um repositório Subversion. Agradeço a leitura e boa utilização dos repositórios!

fonte: http://pwsys.com.br/index.php?option=com_content&view=article&id=67:tutorial-usuario-subversion&catid=41:tutoriais&Itemid=66

NautilusSVN: um cliente SVN para LINUX com poder equivalente ao TORTOISESVN

Standard

Foi criado há pouco tempo uma aplicação bem semelhante ao Tortoisesvn, o qual muitas pessoas na net consideram o mesmo como o mais simples e amigável cliente SVN. ONautilussvn veio cheio de “graça”, e faz bonito no quesito de usabilidade, e destacam-se em recursos os pontos:

  • Checkout
  • Commit
  • Revert
  • Diff (usando Meld ou gvimdiff)
  • Log Viewer
  • Revision e SVN User por colunas
  • Ícones que mostram status (embora muito beta)
  • Autenticação SSL (embora muito beta)
  • Username e password com caixa de diálogo
  • Propriedades editáveis

Quer saber mais sobre o projeto, acesse:

http://code.google.com/p/nautilussvn/

How to ou Tutorial Full do Subversion (SVN) Fácil e prático (e ripado)

Standard

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

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

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

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

Começemos pelo começo !

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

Pausa para explicação! 

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

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

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

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

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

<conceitos>

Repositório!

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

Repositório = Diretório = Pasta

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

Cópia de Trabalho (Working Copy)

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

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

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

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

</conceitos>

Resumão!

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

Vamos Detalhar um pouquinho melhor!

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

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

 

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

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

 

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

O processo é simples. Basta digitar :

$svnadmin  create  <CaminhoDoDiretorio>

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

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

Exemplo Prático:

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

 

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

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

Pausa para alguns conceitos! 

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

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

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

RepositorioAplicacao1

RepositorioAplicacao2

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

 

Repositorio

    +——- Aplicacao1

     ‘——– Aplicacao2

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

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

RepositorioAplicacao

     +——— trunk

     +——— branchs

      ‘———- tags

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Continuando o Exemplo Prático:

Continuando o exemplo anterior

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

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

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

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

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

 

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

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

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

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

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

 

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

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

Continuando o exemplo prático

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

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

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

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

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

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

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

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

 

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

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

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

 

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

 

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

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

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

Exemplo Prático da Vida Real

1. Criando o Repositório em uma pasta qualquer

 

 

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

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

/tmp/repositorios# ls -lh HelloWord/ 

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

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

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

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

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

    <?php echo ‘pagina inicial’; ?> 

/tmp/HelloWord/trunk# ls -lh 

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

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

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

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

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

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

 

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

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


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

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

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

/tmp/HelloWord# ls -lh 

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

 

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

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

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

/tmp/HelloWord# svn status
   
    M      index.php

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

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

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

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

 

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

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

/tmp/HelloWord/cpanel# cd ..
/tmp/HelloWord# svn status
   
    ?      cpanel

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

 

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

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

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

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

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

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

/tmp/HelloWord# svn status

    ?      cpanel/user.php

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

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

    A         cpanel/user.php

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

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

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

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

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

    !      cpanel/user.php

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

/tmp/HelloWord# svn update

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

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

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

 

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

    D         cpanel/user.php

/tmp/HelloWord# ls cpanel -lh

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


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

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

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

/tmp/HelloWord# svn update -r4

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

/tmp/HelloWord# ls cpanel -lh

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

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

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

    HelloWordRevisao4

    HelloWordRevisao5

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

Voltemos para a revisão 5.

/tmp/HelloWord# svn update

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

/tmp/HelloWord# ls cpanel/ -lh

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

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

 

 

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

    A         cpanel/user.php

/tmp/HelloWord# ls cpanel/ -lh

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

/tmp/HelloWord# svn status

    A  +   cpanel/user.php

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

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

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

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

 

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

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

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

    Observe que nada foi retornado, como esperado.

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

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

    cpanel/
    index.php

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

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

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

    Commit da revisão 7.

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

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

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

    versao1.0/

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

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

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

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

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

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

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

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

 

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

Fonte: http://www.ultimolog.com/2007/05/29/controle-de-versao-com-subversion-svn-rapido-e-pratico/

Instalação do Subversion no Ubuntu (sem frescuras!)

Standard

Estava me organizando para uma séria de projetos, nada mais justo que falar para você mesmo que você precisa ser justo com a administração de seu tempo. Estou em um domingo, descansando e disposto a dar mastigadinho (outra vez) o esquema para você:

 

Arena – ou campo de batalha

  1. Instalar o Ubuntu Server sem selecionar as opções de LAMP ou DNS Server (se desejar instalar o lamp agora siga o how to no link -> http://littleoak.wordpress.com/2008/07/04/ubuntu-804-apache2-php5-mysql5-phpmyadmin-lamp2-no-ubuntu-804/
  2. No meu caso, que tem um HD de 10GB, dividi as partições de maneira default (assistido e usar disco inteiro). Instalar o Apache e o SVN:
    • sudo apt-get install apache2 subversion libapache2-svn
  3. Criar o diretório onde ficarão os repositórios do SVN:
    • sudo mkdir /srv/svn
  4. Criar o repositório. Aqui seria um bom momento para restaurar o backup, quando for o caso:
    • sudo svnadmin create /srv/svn/{repositorio}
  5. Dar acesso ao Apache para esses diretórios:
    • sudo chown -R www-data:www-data /srv/svn
  6. Configurar o módulo webdav do subversion
    1. sudo vi /etc/apache2/mods-enabled/dav_svn.conf
    2. Descomentar a tag <Location /svn>. No início e no fim do arquivo.
    3. Descomentar a opção DAV svn
    4. Descomentar a opção SVNParentPath /var/lib/svn e mudar o caminho para a localização do repositório: /srv/svn. Foi escolhido essa ao invés da SVNPath para termos mais de um repositório nesta mesma pasta.
    5. Descomentar a opção AuthzSVNAccessFile /etc/apache2/dav_svn.authz. Para habilitar o controle de acesso aos projetos usando o arquivo informado. Mais informação sobre como criar o arquivo podem ser vistas no livro vermelho do Subversion, na seção Per-Directory Access Control. Infelizmente a versão em português ainda não foi traduzida.
    6. Descomentar, para habilitar a autenticação, as três linhas:
      1. AuthType Basic
      2. AuthName “Subversion Repository”
      3. AuthUserFile /etc/apache2/dav_svn.passwd
      4. Adicione a linha: Require valid-user
      5. Descomente a última informação de </Location>
      6. Salve o arquivo. Para isso, aperte a tecla ESC digite “:wq” sem as aspas e pressione enter
  7. Crie um usuário para acessr o SVN:
    • sudo htpasswd -cm /etc/apache2/dav_svn.passwd <username>
    • O parâmetro -c só é necessário para o primeiro usuário, pois é usado para criar o arquivo. Para os seguintes apenas o -m resolve, que é usado para criptografar a senha com o MD5.
  8. Reiniciar o apache
    • sudo /etc/init.d/apache2 restart