Subversion em Ação

Cópias de Trabalho

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

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.

URLs do Repositório

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:

Tabela 2.1. URLs de Acesso ao Repositório

EsquemaMétodo de Acesso
file:// Acesso direto ao repositório em um local ou dispositivo de rede.
http:// Acesso através do protocolo WebDAV para o módulo Subversion do servidor Apache.
https:// O mesmo que http://, mas com criptografia SSL
svn:// Acesso TCP/IP não autenticado através do protocolo customizado para um servidor svnserve.
svn:ssh:// acesso TCP/IP autenticado e criptografado através de um protocolo customizado para um servidor svnserve

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:

  • Você está concedendo permissão de escrita para todos os usuários, assim, eles podem acidentalmente excluir arquivos ou corromper o sistema de arquivos do repositório.

  • Not all network file sharing protocols support the locking that Subversion requires. One day you will find your repository has been subtly corrupted.

  • Você precisa definir as permissões de acesso da maneira correta. SAMBA é particularmente difícil neste quesito.

  • Se uma pessoa instala uma versão mais recente do cliente que atualiza o formato do repositório, todos os demais serão impossibilitados de acessar o repositório até que também tenham atualizado para a nova versão do cliente.

Revisõ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

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.

Como Cópia de Trabalho Acompanham o Repositório

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

  • what revision your working file is based on (this is called the file's working revision ), and

  • a informação de data/hora de quando foi a última atualização da cópia do repositório.

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:

Não modificado, e atualizado

O arquivo não foi modificado na cópia de trabalho, e nenhuma nova modificação foi submetida no repostório considerando a revisão de trabalho. Um submetero> do arquivo natualizar do arquivo tamb

Localmente alterado, e atualizado

O arquivo possui modificações no diretório de trabalho, e nenhuma modificação para o arquivo foi enviada para o repositório considerando a revisão atual. Existem alterações que não foram submetidas para o repositório, deste modo um submeter do arquivo vai obter sucesso ao publicar suas alterações, e um atualizar do arquivo não fará nada.

Não modificado, e desatualizado

O arquivo não possui alterações no diretório de trabalho, mas há modificações no repositório. O arquivo deverá eventualmente ser atualizado, para sincronizar com a revisão publica. Um submeter do arquivo não fará nada, e um atualizar do arquivo trará as últimas alterações para a cópia local.

Localmente modificado, e desatualizado

O arquivo possui modificações tanto no diretório de trabalho, como no repositório. Um submeter do arquivo vai falhar com o erro desatualizado. O arquivo deverá ser atualizado primeiro; o comando atualizar vai tentar unificar as alterações do repositório com as alterações locais. Se o Subversion não conseguir completar a unificação de forma plausível automaticamente, ele deixará para o usuário resolver o conflito.