Tu já ouviste falar em cópias de trabalho; agora vamos demonstrar como o cliente Subversion as cria e usa.

Uma cópia de trabalho do Subversion é uma normal árvore de pastas no teu sistema local contendo uma colecção de ficheiros. Tu podes editar esses ficheiros como desejares, e no caso de serem ficheiros de código fonte, poderás compilar o teu programa a partir deles da forma habitual. A tua cópia de trabalho é a tua área de trabalho privada: o Subversion nunca irá incorporar alterações de outras pessoas, nem tornar as tuas alterações disponíveis a outros, até tu explicitamente lhe indicares para o fazer.

Após efectuares algumas alterações nos ficheiros da tua cópia de trabalho, e verificares que elas estão correctas, o Subversion ir-te-á fornecer comandos para publicares as tuas alterações para as outras pessoas que trabalham contigo no projecto (escrevendo para o repositório). Se outras pessoas publicarem as suas próprias alterações, o Subversion fornece-te comandos para integrar essas alterações na tua cópia de trabalho (ao ler do repositório).

A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, your working copy contains a subdirectory named .svn, also known as the working copy administrative directory . The files in this administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work. Prior to 1.7 Subversion maintained .svn administrative subdirectories in every versioned directory of your working copy. Subversion 1.7 takes a completely different approach and each working copy now has only one administrative subdirectory which is an immediate child of the root of that working copy.

Um repositório típico do Subversion armazena com frequência os ficheiros (ou código fonte) de vários projectos; normalmente, cada projecto é uma subpasta no sistema de ficheiros do repositório. Nesta configuração, a cópia de trabalho do utilizador corresponde normalmente a uma sub-árvore em particular do repositório.

Por exemplo, supõem que tens um repositório que contém dois projectos de software.

Figura 2.6. O Sistema de Ficheiros do Repositório

Noutras palavras, a pasta raiz do repositório terá duas subpastas: paint e calc.

To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.)

Suppose you make changes to button.c. Since the .svn directory remembers the file's modification date and original contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in ) changes to the repository.

Para publicar as tuas alterações para outros, podes usar o comando submeter do Subversion.

Agora as tuas alterações no button.c foram submetidas para o repositório; se outro utilizador efectuar um checkout de uma cópia de trabalho do /calc, irá ver as tuas alterações na última versão do ficheiro.

Supõem que tens um colaborador, Sally, que efectuou checkout a uma cópia de trabalho do /calc ao mesmo tempo que tu. Quando tu submeteres a tua alteração ao button.c, a cópia de trabalho da Sally irá ficar inalterada; o Subversion só modifica as cópias de trabalho a pedido do utilizador.

Para actualizar o seu projecto, a Sally pode pedir ao Subversion para actualizar a sua cópia de trabalho, usando o comando actualizar do Subversion. Isto irá incorporar as tuas alterações na sua cópia de trabalho, tal como quaisquer outras que tenham sido submetidas desde que a criou (checkout).

Note-se que a Sally não precisou de especificar quais os ficheiros a actualizar; o Subversion usa a informação na pasta .svn, e informação posterior no repositório, para decidir que ficheiros precisam de ser actualizados.

Os repositórios do Subversion podem ser acedidos através de vários métodos diferentes - no disco local, ou através de vários protocolos de rede. No entanto, a localização do repositório será sempre um URL. O esquema do URL indica o método de acesso:

Na maioria dos casos, os URLs do Subversion usam a sintaxe padrão, permitindo a especificação de nomes de servidor e números de porto, como parte do URL. O método de acesso file:// é normalmente usado para acessos locais, embora possa ser usado em caminhos UNC para um hospedeiro de rede. Portanto o URL toma a forma de file://hostname/path/to/repos. Para a máquina local, a parcela do URL hostname pode ser localhost ou ausente. Por esta razão os caminhos locais aparecem normalmente com três barras, file:///path/to/repos.

Igualmente, os utilizadores do esquema file:// nas plataformas Windows, irão precisar de usar uma sintaxe “padrão” não oficial para aceder aos repositórios que estão na mesma máquina, mas numa unidade diferente da unidade de trabalho do utilizador. Qualquer uma da duas seguintes sintaxes de caminhos URL irão funcionar aqui, X é a unidade onde reside o repositório:

file:///X:/path/to/repos
...
file:///X|/path/to/repos
...
      

Observa que o URL usa barras comuns, mesmo que a forma nativa de um caminho (sem-URL) no Windows utilize barras invertidas.

Você pode acessar um repositorio FSFS via uma rede compartilhada, mas isso não é recomendado por várias razões:

Uma operação svn submeter pode publicar alterações de qualquer número de ficheiros e pastas, como uma transacção atómica. Na tua cópia de trabalho, tu podes alterar o conteúdo dos ficheiros, criar, remover, alterar o nome e copiar ficheiros e pastas, e então submeter o conjunto completo de alterações como uma unidade.

No repositório, cada submissão é tratada como uma transacção atómica: ou todas as alterações da submissão ocorrem, ou nenhuma ocorrerá. O Subversion mantém a sua atomicidade em caso de estoiro do programa, problemas de rede, ou outras acções dos utilizadores.

Cada vez que o repositório aceita uma submissão, este cria um novo estado da árvore do sistema de ficheiros chamado revisão. A cada revisão é atribuído um número natural, uma unidade acima à da revisão prévia. A revisão inicial de um repositório recém-criado é zero, e consiste em nada mais que uma pasta raiz vazia.

Uma maneira agradável de visualizar o repositório é como uma série de árvores. Imagina um array de números de revisão, a começar no 0, alinhados da esquerda para a direita. Cada número de revisão tem uma árvore de revisão por baixo, e cada árvore é uma “fotografia” do aspecto do repositório após cada submissão.

Figura 2.7. O repositório

É importante observar que as cópias de trabalho nem sempre correspondem a um única revisão do repositório; Elas podem conter ficheiros de várias revisões diferentes. Por exemplo, supõe que efectuas o checkout de um repositório para uma cópia de trabalho, cuja revisão mais recente é 4:

calc/Makefile:4
integer.c:4
button.c:4
      

Neste momento, esta cópia de trabalho corresponde exactamente à revisão 4 do repositório. No entanto, supõe que fizeste uma alteração ao button.c, e submetes essa alteração. Assumindo que não foram efectuadas outras submissões, a tua submissão irá criar a revisão 5, e a tua cópia de trabalho irá ficar assim:

calc/Makefile:4
integer.c:4
button.c:5
      

Supõe que, neste momento, a Sally submete uma alteração ao integer.c, criando a revisão 6. Se usares o svn actualizar para actualizares a tua cópia de trabalho, ela irá ficar do seguinte modo:

calc/Makefile:6
integer.c:6
button.c:6
      

As alterações da Sally ao integer.c irão aparecer na tua cópia de trabalho e a tua alteração no button.c ainda estará presente. Neste exemplo, o texto do Makefile será identico nas revisões 4,5,6 mas o Subversion irá marcar a tua cópia de trabalho do Makefile com a revisão 6, para indicar que esta é ainda a corrente. Então, após uma actualização de limpeza no topo da tua cópia de trabalho, esta irá corresponder a exactamente uma revisão do repositório.

Para cada ficheiro na pasta de trabalho, o Subversion guarda duas partes essenciais de informação na área administrativa .svn/:

Dada esta informação, comunicando com o repositório, o Subversion pode dizer em qual dos seguintes quatro estados está o ficheiro de trabalho: