Você está pronto para ler sobre cópias de trabalho; agora vamos demonstrar como o aplicativo do Subversion cria e usa as cópias.

Uma cópia de trabalho do Subversion é uma estrutura de diretórios como outra qualquer em seu sistema local, contendo um conjunto de arquivos. Vocë pode editar esses arquivos como desejar, e se os arquivos são códigos fonte, você pode compilar seu programa a partir desta cópia como sempre fez. Sua cópia de trabalho é sua própria área pessoal. Subversion nunca vai incorporar alterações de outras pessoas, nem disponibilizar suas alterações para outros, até que você mesmo o faça.

Depois que você fez algumas modificações nos seus arquivos em sua cópia de trabalho e verificou que estão funcionando corretamente, Subversion provê a você comandos para publicar suas alterações para outras pessoas que trabalham com você em seu projeto (através da escrita no repositório). Se outras pessoas publicarem suas próprias modificações, Subversion provê comandos para unificar estas modificações na sua cópia de trabalho (através da leitura 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 geralmente guarda os arquivos (ou código fonte) para diversos projetos; normalmente, cada projeto é um subdiretório na estrutura de arquivos do repositório. Desta forma, uma cópia de trabalho de um usuário normalmente corresponde a uma específica subestrutura do repositório.

Por exemplo, suponha que você tenha um repositório que contem dois projetos de software.

Figura 2.6. O Sistema de Arquivos do Repositório

Em outras palavras, o diretório principal do repositório tem dois subdiretórios: 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 suas modificações para outras pessoas, você pode usar o commando submeter do Subversion.

Agora suas modificações para button.c foram enviadas para o repositório; se outro usuário obter uma cópia de /calc, eles verão suas modificações na última versão do arquivo.

Suponha que vocë tenha uma colaboradora, Sally, que obteve uma cópia de /calc no mesmo momento que você. Quando você submeter suas modificações de button.c, a cópia de trabalho de Sally não será modificada; Subversion somente modificará as cópias dos usuários que solicitarem a atualização.

Para atualizar seu projeto, Sally deve pedir ao Subversion para atualizar sua cópia de trabalho, através do comando atualizar do Subversion. Isto incorporará sua modificação na cópia de trabalho dela, assim como qualquer outra modificação que tenha sido submetido desde que ela obteve sua cópia de trabalho.

Note que Sally não precisou especificar quais arquivos atualizar; Subversion usa a informação do diretório .svn, e além disso informações do repositório, para decidir quais arquivos precisam ser atualizados.

Repositórios do Subversion podem ser acessados através de vários métodos direfentes - como disco local, ou através de vários protocolos de rede. Um local de repositório, contudo, é sempre uma URL. O esquema de URL indica o método de acesso:

Para a maioria, URLs do Subversion usam a sintaxe padrão, permitido nomes de servidores e números de porta em uma parte específica da URL. O método de acesso file:// é normalmente usado para acesso local, apesar de que isto pode ser usado com caminhos UNC em uma máquina da rede. A URL portanto usa o formato file://hostname/path/to/repos. Para a máquina local, a parte do hostname da URL deve ser suprimida ou deve ser localhost. Por esta razão, caminhos locais normalmente aparecem com três barras, file:///path/to/repos.

Também, usuários do esquema file:// em plataformas Windows vão precisar usar uma sintaxe “padrão” não oficial para acessar repositórios que estão na mesmo máquina, mas em um dispositivo diferente que o atual dispositivo de trabalho da máquina. Qualquer uma das duas seguintes sintaxes funcionarão onde X é o dispositivo no qual o repositório está:

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

Note que a URL usa barras normais embora a forma nativa (não URL) de um caminho no Windows seja barra invertida.

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

Um comando svn submeter pode publicar modificações de qualquer quantidade de arquivos e diretórios como uma única transação atômica. Em sua cópia de trabalho, você pode mudar o conteudo de um arquivo, criar, excluir, renomear e copiar arquivos e diretórios, e depois enviar todas as modificações como uma única e completa alteração.

Em um repositório, cada submissão é tratada como uma transação atômica: ou todas as mudanças são enviadas, ou nenhuma delas. Subversion mantém essa atomicidade por causa de falhas de programas, falhas de sistema, falhas de rede, e ações de outros usuários.

Cada vez que o repositório aceita uma submissão, ele cria um novo estado da estrutura de arquivos, chamada de revisão. Cada revisão é associada a um número natural, maior que o número da revisão anterior. A revisão inicial de um repositório recém criado é zero, e não contém nada mais que um diretório principal vazio.

Uma maneira interessante de enxergar o repositório é como uma série de estruturas. Imagine uma matriz de números de revisões, começando em 0, e se estendendo da esquerda para a direita. Cada número de revisão com uma estrutura de arquivos abaixo, e cada divisão já em seguida da maneira como o repositório realizou cada submissão.

Figura 2.7. O Repositório

É importante notar que cópias de trabalho nem sempre correspondem a uma única revisão qualquer no repositório; eles podem conter arquivos de diferentes revisões. Por exemplo, suponha que você obteve uma cópia de trabalho de um repositório do qual a revisão mais recente é a 4:

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

Neste momento, esta cópia de trabalho corresponde exatamente à revisão 4 no repositório. Entretanto, suponha que você fez modificações em button.c, e submeteu essas alterações. Assumindo que não houve nenhuma outra submissão, o envio vai criar a revisão 5 no repositório, e sua cópia de trabalho vai se parecer com isto:

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

Suponha que, neste momento, Sally envia uma alteração do integer.c, criando a revisão 6. Se você usar o svn atualizar para atualizar sua cópia de trabalho, então você terá algo como isto:

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

As modificações de Sally para integer.c vão aparecer em sua cópia de trabalho, e sua alteração vai continuar presente em button.c. Neste exemplo, o texto de Makefile é identifico nas revisões 4, 5 e 6, mas Subversion vai marcar sua cópia de trabalho do Makefile com a revisão 6 indicando que ainda é a versão atual. Então, depois que você completou todas as atualizações na sua cópia de trabalho, isto geralmente corresponderá a uma exata revisão do repositório.

Para cada arquivo do diretório de trabalho, Subversion grava duas partes essenciais da informação na área administrativa .svn/:

Com estas informação, através de troca de informações com o repositório, Subversion pode identificar qual dos quatro estados seguintes é o estado de um arquivo: