O TortoiseSVN está disponível para Windows Vista ou superior, nas versões 32 e 64 bits. O instalador da versão 64-bit para Windows também inclui os arquivos necessários para a versão 32 bits. Isso significa que não é preciso instalar esta versão separadamente para poder utilizá-la nas aplicações de 32 bits.

O suporte para Windows 98, Windows ME e Windows NT4 foi descontinuado na versão 1.2.0, ao passo que o suporte para Windows 2000 e XP até o SP2 acabou na versão 1.7.0. O suporte para Windows XP com o SP3 terminou na versão 1.9.0. Entretanto, você ainda pode baixar e instalar essas versões mais antigas caso necessite delas.

TortoiseSVN vem com um instalador fácil de usar. Clique duas vezes no arquivo de instalação e siga as instruções. O instalador cuidará de todo o resto. Não se esqueça de reiniciar após a instalação.

Pacotes de linguagens estão disponíveis, podendo traduzir a interface do TortoiseSVN para muitas diferentes línguas. Por favor, dê uma olhada em Apêndice G, Pacotes de Idiomas e Corretores Ortográficos para mais informações em como as instalar.

Se você tiver qualquer problema durante ou após a instalação do TortoiseSVN, por favor acesse nosso FAQ disponível em http://tortoisesvn.net/faq.html.

Para um projeto real você terá um repositório configurado em algum lugar seguro e um servidor do Subversion para ser controlado. Para os propósitos deste tutorial nós usaremos um repositório local do Subversion que tem como característica o acesso direto ao repositório criado no seu disco sem a necessidade de um servidor.

Primeiro, crie um diretório novo vazio no seu computador. Pode ser em qualquer lugar e ter qualquer nome, mas neste tutorial nós o chamaremos C:\svn_repos. Agora, clique com o botão direito na pasta criada e, no menu de contexto, escolha TortoiseSVN → Criar um repositório aqui.... O repositório é então criado dentro da pasta, pronto para ser usado. Também criaremos a estrutura interna padrão de pastas clicando no botão Criar estrutura de pasta

Agora temos um repositório, mas está completamente vazio no momento. Suponhamos que há alguns arquivos em C:\Projects\Widget1 que eu gostaria de adicionar. Navegue para a pasta Widget1 pelo Explorer e clique com o botão direto sobre ela. Agora seleiona TortoiseSVN → Importar... que vai mostrar uma janela

Figura 1.2. A Janela de Importação

Um repositório do Subversion é reconhecido pela URL, que nos permite especificar um repositório em qualquer lugar na Internet. Neste caso, precisamos apontar para nosso próprio repositório local que tem a URL file:///c:/svn_repos/trunk, ao qual adicionamos nosso próximo nome para o projeto Widget1. Note que há 3 barras depois de file: e que eles são mesmo usados.

Outra importante característica desta janela é a caixa Mensagem Importante a qual lhe permite digitar uma mensagem descrevendo o que você está fazendo. Quando você visualizar o histórico do seu projeto, essas mensagens serão um valioso guia para entender as alterações feitas e porque. Neste caso nós podemos dizer algo simples como “Importar o Projeto Componente1”. Clicar no OK e o diretório será adicionado ao seu repositório.

Agora que há um projeto em nosso repositório, precisamos criar uma cópia de trabalho para usar nas tarefas do dia-a-dia. Note que o ato de importar uma pasta não a transforma automaticamente em uma cópia de trabalho. O termo do Subversion para criar uma nova cópia de trabalho é Checkout. Vamos fazer o checkout da pasta Widget1 do nosso repositório para uma pasta de desenvolvimento chamada C:\Projects\Widget1-Dev. Crie essa pasta, depois clique com o botão direito do mouse sobre ela e selecione TortoiseSVNCheckout...

Você notará que a aparência deste diretório será diferente do diretório original. Cada arquivo terá uma marca verde no canto inferior esquerdo. Esses ícones de situação do TortoiseSVN estarão presentes apenas na cópia de trabalho. A situação verde indica que o arquivo não foi alterado em relação à versão do repositório.

Hora de trabalhar. Digamos que os arquivos 2Componente1.c2 e 3ReadMe.txt3da pasta Componente1-Dev foram editados. Note que a sobreposição de ícones nestes arquivos estão agora em cor vermelha, indicando que há alterações locais nos mesmos.

Mas o que nós fizemos? Clique com o botão direito em um dos arquivos alterados e selecione TortoiseSVN → Diferenças. A ferramenta de comparação do TortoiseSVN será aberta, mostrando exatamente quais linhas foram modificadas.

Figura 1.3. Visualizador das Diferenças do Arquivo

Bom, então nós estamos felizes com as alterações, vamos atualizar o repositório. Esta ação é referenciada como Submissão das alterações. Clique com o botão direito sobre o diretório Componente1-Dev e selecione TortoiseSVN → Submeter. A janela de submissão mostrará os arquivos alterados, cada um com uma caixa de seleção. Você pode querer escolher apenas alguns dos arquivos, mas neste caso nõs vamos submeter as alterações em ambos os arquivos. Digite uma mensagem para descrever sobre o que são as alterações e clique em OK. A janela de progresso mostrará os arquivos sendo enviados para o repositório e então está feito.

Como os desenvolvedores precisarão adicionar novos arquivos - vamos dizer que você adicionou alguma nova funcionalidade em Extras.c e adicionou um referência no arquivo que já existia Makefile. Clique com o botão direito sobre o diretório e selecione TortoiseSVN → Adicionar. A janela de Adição gora mostra para você todos os arquivos não controlados e você poderá selecionar cada um que você quer adicionar. Outra forma de adicionar arquivos poderá ser um clique com o botão direito sobre o próprio arquivo e então selecionar TortoiseSVN → Adicionar.

Agora quando você for submeter o diretório, o novo arquivo aparecerá como Adicionado e o arquivo já existente como Modificado. Note que você pode dar um duplo clique sobre o arquivo modificado e verificar exatamente as alterações feitas.

Uma das características mais úteis do TortoiseSVN é a janela de Auditoria. A janela mostra a você a lista de todos os commits feitos para um arquivo ou diretório, e mostra detalhadamente as mensagens que você digitou (você digitou uma mensagem para o commit como sugerido? Se não, agora você vê porque isso é importante).

Figura 1.4. A Janela de Log

Bem, então eu manipulei um pouco aqui e usei uma imagem do repositório do TortoiseSVN.

O painel superior mostra a lista das revisões submetidas e o início da mensagem relacionada. Se você selecionar uma dessas revisões, o painel do meio mostrará a mensagem completa para a revisão e o painel de baixo mostrará a lista dos arquivos e diretórios modificados.

Cada um dos painéis possui um menu de contexto que provê a você várias maneiras de usar a informação. No painel inferior você pode dar um duplo clique em um arquivo e ver exatamente as alterações feitas naquela revisão. Leia “Janela de Revisão de Registro” para ver o texto completo.

Umas das características de todo sistema de controle de revisão é que eles permitem a você desfazer alterações feitas anteriormente. Como você pode esperar, TortoiseSVN faz isso de forma simples.

Se você quer controlar as mudanças que você fez e ainda não submeteu e desfazer essas mudanças voltando para a versão original, TortoiseSVN → Reverter

Se você quer desfazer as alterações de uma revisão em particular, abra a janela de Auditoria e encontre a revisão em questão. Selecione Menu de Contexto → Reverter alterações desta revisão e então as alterações da revisão serão desfeitas.

Considere o cenário: suponha que nós temos dois usuários, Harry e Sally. Cada um deles decide editar o mesmo arquivo no mesmo repositório ao mesmo tempo. Se Harry salvar suas alterações no repositório primeiro, é possível que (alguns tempo depois) Sally poderia acidentalmente sobreescrever as alterações com sua versão do arquivo. Enquanto a versão do arquivo do Harry se perderia para sempre (porque o sistema guarda cada modificação), qualquer alteração que Harry fez não estariam presentes na nova versão do arquivo de Sally, porque ela nunca viu as modificações do Harry. O trabalho do Harry foi perdido - ou no mínimo estaria na versão mais recente - e provavelmente por acidente. Esta é definitivamente um situação que nós queremos evitar!

Figura 2.2. O problema a ser evitado

Muitos sistemas de controle de versão usam o modelo alocar-modificar-desalocar para resolver este problema, o qual é uma solução simples. Em cada sistema, o repositório permite somente uma pessoa por vez modificar o arquivo. Primeiro Harry deve alocar o arquivo antes que possa fazer as alterações. Alocar um arquivo é como um controle de biblioteca/ se Harry alocou o arquivo, então Sally não pode fazer qualquer alteração nele. Se ela tentar alocar o arquivo, o repositório vai negar essa solicitação. Tudo que ela pode fazer é ler o arquivo, e esperar até que Harry acabe as suas alterações e libere o arquivo. Depois que Harry desalocar o arquivo, sua vez acaba, e então é a vez de Sally alocar o arquivo e fazer suas alterações.

Figura 2.3. A solução Alocar-Modificar-Desalocar

O problema com o modelo alocar-modificar-desalocar é que é muito restritivo, e muitas vezes é um empecilho para os usuários:

Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

Aqui vai um exemplo. Digamos que Harry e Sally criam cada um uma cópia de trabalho de um mesmo projeto, copiado do repositório. Eles trabalham ao mesmo tempo, e fazem modificações em um mesmo arquivo A em suas cópias. Sally salva suas alterações no repositório primeiro. Quando Harry tenta salvar suas modificações após Sally, o repositório informa a ele que o arquivo A está desatualizado. Em outras palavras, o arquivo A do repositório tem alguma alteração desde a última vez que ele foi copiado. Então Harry é questionado sobre a unificação das modificações no repositório serem inseridas em sua cópia do arquivo A. Oportunamente as modicações de Sally não foram sobreescritas pelas dele; uma vez que ele unificou ambas as alterações, ele salva a sua cópia no repositório.

Figura 2.4. A solução Copiar-Modificar-Unificar

Figura 2.5. ...Continuando com Copiar-Modificar-Unificar

Mas o que acontece se as alterações de Sally se sobrepoem sobre as alterações de Harry? O que então deve ser feito? Esta situação é chamada de conflito, e em geral isto não é um problema. Quando Harry for questionado sobre a unificação das últimas alterações no repositório em sua cópia de trabalho, sua cópia do arquivo A de qualquer maneira é marcada como conflitante: ele verá todas as modificações em conflito, e manualmente resolverá. Entenda que o software não pode resolver automaticamente os conflitos; somente humanos são capazes de entender quais são as escolhas lógicas a serem tomadas. Uma vez que Harry manualmente resolveu o que estava se sobreponde (talvez precise discutir o conflito com Sally!), ele pode seguramente salvar o arquivo unificado de volta no repositório.

O modelo copiar-modificar-unificar pode parecer bagunçado, mas na prática, isto funciona grandemente. Usuários podem trabalhar paralelamente, sem esperar por outros. Quando eles trabalham num mesmo arquivo, a maioria das alterações não se sobrepoem; conflitos são pouco frequentes. E na maioria das vezes o tempo que leva para resolver os conflitos é muito menor que o tempo perdido em um sistema de alocação.

No final das contas, tudo isso acaba em um ponto crítico: comunicação entre os usuários. Quando os usuários não se comunicam direito, aumenta-se os conflitos sintáticos e semênticos. Nenhum sistema pode forçar uma perfeita comunicação, nenhum sistema pode detectar conflitos de semântica. Então não há porque se entusiasmar com falsas promessas de que um sistema de alocação evitará conflitos; na prática, alocações parecem restringir a produtividade mais que qualquer outra cosa.

Existe uma situação em comum onde o modelo alocar-modificar-desalocar se torna melhor, e é com arquivos que não são unificáveis. Por exemplo, se seu repositório contém alguns arquivos de imagens, e duas pessoas mudam a imagem ao mesmo tempo, não há nenhuma maneira de combinar as alterações. Ou Harry ou Sally perderá sua alteração.

Subversion usa a solução copiar-modificar-unificar como padrão, e na maioria dos casos é o suficiente. Contudo, a partir da versão 1.2, Subversion também permite alocar um arquivo, e se existem arquivos que não são unificáveis, você pode adotar uma política de alocação, que o Subversion está preparado para o que você precisa.

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:

Agora você tem uma novo repositório localizado em D:\SVN\MyNewRepository.

Para acessar seu repositório local você precisa do caminho para a pasta. Apenas lembre-se que Subversion esperar todos os caminhos dos repositórios no formato file:///C:/SVNRepository/. Note o uso de barras em todo o caminho.

Para acessar o repositório localizado em uma rede compartilhada você pode também usar uma unidade mapeada, ou você pode usar um caminho UNC. Para caminhos UNC, o formato é file://NomeServidor/caminho/para/repos/. No que há apenas 2 barras aqui.

Antes do SVN 1.2, caminhos UNC tinham que ser informados num formato mais complicado file:///\NomeServidor/caminho/para/repos. Este formato ainda é suportado, mas não é recomendado.

Although in theory it is possible to put a FSFS repository on a network share and have multiple users access it using file:// protocol, this is most definitely not recommended. In fact we would strongly discourage it, and do not support such use for various reasons:

O acesso através de file:// é destinado para local, um único usuário, e particularmente para testes e depurações. Quando você quer compartilhar o repositório você realmente deve configurar um servidor, e isto não é tão difícil como você deve estar pensando. Leia “Acessando o Repositório” para orientações sobre escolhas e configurações de um servidor.

Antes de você importar seus dados para o repositório você deve primeiro pensar sobre como você quer organizar os dados. Se você usar um dos formatos recomendados depois você o terá muito mais organizado.

Existem alguns padrões e recomendadas maneiras de organizar um repositório. Muitas pessoas criam um diretório trunk para guardar a “linha principal” de desenvolvimento, um diretório branches para guardar as ramificações, e um diretório tags para guardar as versões concluidas. Se o repositório guarda somente um único projeto, então frequentemente as pessoas criam estes diretórios no nível mais alto:

/trunk
/branches
/tags
    

Porque este formato é tão comumente usado, quando você criar um novo repositório usando o TortoiseSVN, ele também oferecerá a criação da estrutura de diretórios para você.

Se o repositório contém vários projetos, as pessoas normalmente organizam sua estrutura por ramificação:

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc
    

... ou por projeto:

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags
    

Organizar por projeto faz sentido se os projetos não são fortemente relacionados e cada um deles é controlado individualmente. Para projetos relacionados onde você pode querer controlar todos os projeto de uma vez, ou onde os projetos são todos amarrados uns aos outros em um único pacote de distribuição, é então mais comum organizar por ramificação. Desta maneira você tem somente um trunk para controlar, e os relacionamentos entre os subprojetos são vislumbrados mais facilmente.

Se você adotar como nível mais alto algo como/trunk /tags /branches, não há nada para dizer que você tenha que copiar o trunk inteiro para cada ramificação e liberação, e de alguma forma esta estrutura oferece mais flexibilidade.

Para projetos não relacionados você deve dar preferência para repositórios separados. Quando você submeter alterações, o novo número de revisão será do repositório inteiro, não o apenas a revisão do projeto. Tendo 2 projetos não relacionados compartilhando um mesmo repositório pode significar grandes lacunas no número da revisão. Os projetos Subversion e o TortoiseSVN aparecem no mesmo endereço principal, mas são repositórios completamente separados permitindo o desenvolvimento independente, e sem confusões no número da liberação.

Claro, você é livre para ignorar estes leiautes padrões. Você pode criar qualquer tipo de variação, seja o que funcionar melhor para você e sua equipe. Lembre-se que qualquer que seja a sua escolha, isto não é uma decisão permanente. Você pode reorganizar seu repositório a qualquer momento. Pelos diretórios branches e tags serem diretórios comuns, TortoiseSVN pode mover ou renomeá-los do jeito que você quiser.

Mudar de um leiaute para outro é apenas questão de mover uns diretórios no servidor; se você não gosta da maneira que as coisas estão organizadas no repositório, basta manipular os diretórios no repositório.

Então se você ainda não tem criada uma estrutura base de diretórios dentro do seu repositório você deverá fazer agora. Existem duas maneiras de fazer isso. Se você simplesmente quer criar uma estrutura /trunk /tags /branches, você pode usar o navegador de repositórios para criar as três pastas (em três separadas submissões). Se você quer criar um hierarquia mais estruturada então crie a estrutura primeiro no disco local e importe-a em uma única submissão, como isto:

Note that the name of the folder you are importing does not appear in the repository, only its contents. For example, create the following folder structure:

C:\Temp\New\trunk
C:\Temp\New\branches
C:\Temp\New\tags
      

Import C:\Temp\New into the repository root, which will then look like this:

/trunk
/branches
/tags
      

Figura 4.1. Explorer mostra os ícones sobrepostos

Um dos recursos mais visíveis do TortoiseSVN é o de sobreposição de ícones que aparece em arquivos em sua cópia de trabalho. Eles te mostram em um instante quais de seus arquivos foram modificados. Consulte “Sobreposição dos Ícones” para descobrir o que as diferentes sobreposições representam.

Figura 4.2. Menu do contexto para diretórios controlados

Todos os comandos do TortoiseSVN são acessados através do menu de contexto do Windows Explorer. A maioria são diretamente visíveis quando se clica com o botão direito em um arquivo ou diretório. Os comandos estarão disponíveis se o arquivo ou o diretório que o contém está no controle de versão. Você também pode acessar o menu do TortoiseSVN como parte do menu Arquivo, no Windows Explorer.

Em alguns casos você poderá ver várias entradas do TortoiseSVN. Isto não é um bug!

Figura 4.3. Atalho no menu arquivo do Explorer em um diretório controlado

Este exemplo é de um atalho não-versionado dentro de um diretório versionado, e no menu Arquivo do Windows Explorer há três entradas para o TortoiseSVN. Uma para o diretório, uma para o atalho, e uma terceira para o objeto para o qual o atalho aponta. Para ajudar a distinguir entre elas, os ícones um indicador no canto inferior direito para mostrar se a entrada se refere a um arquivo, um diretório, um atalho ou para múltiplos ítens selecionados.

Figura 4.4. Menu de quando se clica com o botão direito e se arrasta um diretório que está sob o controle de versão.

Outros comandos estão disponíveis ao se clicar e arrastar, quando você clica com o botão direito e arrasta arquivos ou diretórios para um novo endereço dentro da cópia de trabalho ou quando você clica com o botão direito e arrasta um arquivo ou diretório não versionado para um diretório sob o controle de versão.

Algumas operações comuns do Windows tem atalhos bem conhecidos, mas não aparecem em botões e menus. Se você não sabe como fazer algo óbvio como atualizar uma visualização, cheque aqui.

Se o repositório que você está tentando acessar é protegido por senha, uma janela de autenticação aparecerá.

Figura 4.5. Janela de Autenticação

Entre seu nome de usuário e senha. A caixa de seleção (checkbox) fará com que o TortoiseSVN guarde suas credenciais no diretório padrão do Subversion. %APPDATA%\Subversion\auth na árvore de subdiretórios:

If you want to clear the authentication cache, you can do so from the Saved Data page of TortoiseSVN's settings dialog. The button Clear all will clear the cached authentication data for all repositories. The button Clear... however will show a dialog where you can chose which cached authentication data should be deleted. Refer to “Dados de configuração salvos”.

Some people like to have the authentication data deleted when they log off Windows, or on shutdown. The way to do that is to use a shutdown script to delete the %APPDATA%\Subversion\auth directory, e.g.

@echo off
rmdir /s /q "%APPDATA%\Subversion\auth"
      

You can find a description of how to install such scripts at http://www.windows-help-central.com/windows-shutdown-script.html.

Para mais informações sobre como configurr seu servidor para autenticação e controle de acesso, verifique “Acessando o Repositório”.

Muitas das janelas do TortoiseSVN contém muita informação para mostrar, mas é frequentemente útil maximizar apenas a altura ou apenas a largura da janela, ao invés de maximizar na tela toda. Por conveniência, há atalhos para isto no botão Maximizar. Use o botão do meio do mouse para maximizar verticalmente, e o botão direito do mouse para maximizar horizontalmente.

Se você está importando dados para um repositório existente que já contém algum projeto, a estrutura desse repositório já deverá estar definida. Se você está importando dados para um novo repositório, recomenda-se que dispense algum tempo para definir como esse repositório será organizado. Leia “Leiaute do Repositório” para recomendações adicionais.

Esta secção descreve o comando importar do Subversion, que foi desenhado para importar uma hierarquia de pastas para o repositório de uma só vez. Apesar de efectuar o trabalho, tem algumas deficiências:

Por essas razões recomendamos que não uses de modo algum o comando importar mas em alternativa segue o metodo de dois-passos descrito em “Importando na Pasta”,a não ser que estejas a executar o único passo de criar uma estrutura inicial /trunk /tags /branches no teu repositório. Uma vez que aqui estás, é assim como funciona o importar básico...

Antes de importar seu projeto para um repositório, você deveria:

Agora selecione a pasta de nível superior da sua estrutura de diretório do projeto no Windows Explorer e com o botão direito clique para abrir o menu de contexto. Selecione o comando TortoiseSVN → Importar ...

In this dialog you have to enter the URL of the repository location where you want to import your project. It is very important to realise that the local folder you are importing does not itself appear in the repository, only its content. For example if you have a structure:

C:\Projects\Widget\source
C:\Projects\Widget\doc
C:\Projects\Widget\images
      

and you import C:\Projects\Widget into http://mydomain.com/svn/trunk then you may be surprised to find that your subdirectories go straight into trunk rather than being in a Widget subdirectory. You need to specify the subdirectory as part of the URL, http://mydomain.com/svn/trunk/Widget-X. Note that the import command will automatically create subdirectories within the repository if they do not exist.

A mensagem de importação é usada como uma mensagem para o histórico.

Por padrão, arquivos e pastas que correspondem aos padrões globais de pastas/arquivos ignorados, não são importados. Para contornar esse comportamento você pode utilizar o recurso Incluir arquivos ignorados. Consulte “Configurações Gerais” para obter mais informações sobre como definir um padrão global para ignorar pastas/arquivos.

Assim que clicar em OK TortoiseSVN inicia a importação da "árvore" de diretórios, incluindo todos os arquivos. O projeto estará armazenado no repositório sob controle de versão. Por favor note que a pasta que você importou NÃO está sob controle de versão! Para obter uma cópia de trabalho com versão controlada, você deverá fazer um Checkout da versão que você acabou de importar. Ou continue lendo sobre como proceder em "Importando na Pasta".

Assumindo que você já possui um repositório e que deseja adicionar uma nova pasta na estrutura desse repositório, apenas siga estes passos:

Às vezes, você precisa ter um arquivo sob controle de versão que contém dados específicos de usuário. Isso significa que você terá um arquivo que todo desenvolvedor/usuário precisará modificar para adequá-lo a sua configuração local. Portanto, é difícil manter um arquivo sob controle de versão porque cada usuário poderá submeter alterações no repositório constantemente.

Nesses casos, sugere-se a utilização de um arquivo modelo. Crie um arquivo que contém todos os dados que seus desenvolvedores necessitam, adicione e mantenha esse arquivo sob controle de versão e permita que os desenvolvedores façam o Checkout desse arquivo. Em seguida, cada desenvolvedor deverá fazer uma cópiaemphasis> desse arquivo e renomear essa c

As an example, you can have a look at TortoiseSVN's build script. It calls a file named default.build.user which doesn't exist in the repository. Only the file default.build.user.tmpl. default.build.user.tmpl is the template file which every developer has to create a copy from and rename that file to default.build.user. Inside that file, we added comments so that the users will see which lines they have to edit and change according to their local setup to get it working.

So as not to disturb the users, we also added the file default.build.user to the ignore list of its parent folder, i.e. we've set the Subversion property svn:ignore to include that filename. That way it won't show up as unversioned on every commit.

Você pode escolher a profundidade que você quer obter, o qual permitirá a você especificar a profundidade da recursão nos sub diretórios. Se você quer apenas algumas seções de uma grande hierarquia, você pode obter o nível mais alto apenas, e depois atualizar pastas específicas recursivamente.

Para facilmente seleccionar apenas os itens que pretendes para o checkout e forçar a cópia de trabalho a manter apenas esses itens, clica no botão Escolher itens.... Isto abre uma nova caixa de diálogo onde podes verificar todos os itens que pretendes da tua cópia de trabalho e desseleccionar todos os itens que não pretendes. A cópia de trabalho resultante é conhecida como um checkout disperso. Uma actualização a tal cópia de trabalho não irá obter os ficheiros e pastas em falta, mas apernas actualizar o que já tens actualmente na tua cópia de trabalho.

If you check out a sparse working copy (i.e., by choosing something other than fully recursive for the checkout depth), you can easily add or remove sub-folders later using one of the following methods.

Esta funcionalidade é muito útil quando você apenas quer obter partes de uma grande estrutura, mas você quer a conveniência de atualizar uma só cópia de trabalho. Supondo que você tenha uma grande estrutura a qual possui sub diretórios Projeto01 até Projeto99, e você quer apenas obter o Projeto03, Projeto25 e Projeto76. Use esses passos:

Se sua cópia de trabalho estiver atualizada e não houver conflitos, você está pronto para submeter suas alterações. Selecione qualquer arquivo e/ou pastas que você quiser submeter, então TortoiseSVN → Commit....

Figura 4.7. A janela de Submissão

A janela de submissão irá exibir todos os arquivos modificados, incluindo arquivos adicionados, deletados e não versionados. Se você não quiser que um arquivo alterado seja submetido, apenas desmarque o arquivo. Se você quiser incluir um arquivo não versionado, apenas marque o arquivo para adiciona-lo a submissão

To quickly check or uncheck types of files like all versioned files or all modified files, click the link items just above the list of shown items.

Para informação sobre as colorações das sobreposições de itens de acordo com o seu estado, por favor consulta “Estado Local e Remoto”.

Items que foram movidos para um caminho de repositório diferente são também indicados usando o marcador (s). Você pode ter movido algo enquanto trabalhava em uma ramificação (branch) e se esqueceu de mover de volta para a versão principal (trunk). Esté é seu sinal de aviso!

Click duplo em qualquer arquivo modificado na janela de submissão irá abrir um programa de diff exibindo suas modificações. O menu de contexto irá dar mais opções, como exibido na screenshot. Você também arrastar arquivos da janela de submissão para outros aplicativos como editores de textos ou IDEs.

Você pode selecionar ou deselecionar items clicando na caixa de seleção a esquerda do item. Para diretórios você pode usar Shift-select para fazer a ação recursiva.

As colunas mostradas no painel inferior são personalizadas. Se você clicar com o botão direito em qualquer cabeçalho de coluna você virá um menu de contexto que permitirá a você selecionar quais colunas você quer ver. Você pode também mudar o tamanho da coluna usando a opção de arrasto que aparece quando você mantém o ponteiro do mouse sobre a borda da coluna. Estas personalizações são gravadas, etnão você verá a tela do mesmo jeito quando voltar.

Por padrão quando você submete alterações, qualquer travamento que você determinou em arquivos serão liberados automaticamente após a confirmação da submissão. Se você quer manter as alocações, tenha certeza que a opção Manter bloqueios está selecionada. O padrão desta caixa de seleção é obtido da opção no_unlock do arquivo de configuração do Subversion. Leia “Configurações Gerais” para mais informações sobre como editar o arquivo de configuração do Subversion.

A janela de submissão suporta a funcionalidade lista de alterações do Subversion para ajudar a agrupar arquivos com modificações relacionadas. Saiba mais sobre essa funcionalidade em “Lista de Alterações”.

Às vezes, poderás querer efectuar a submissão de apenas uma parte das alterações que efectuaste num ficheiro. Essa situação acontece com frequência quando estás a trabalhar em algo, e surge uma correcção urgente para ser submetida, e essa correcção calha estar no mesmo ficheiro em que estás a trabalhar.

right click on the file and use Context Menu → Restore after commit. This will create a copy of the file as it is. Then you can edit the file, e.g. in a text editor and undo all the changes you don't want to commit. After saving those changes you can commit the file.

Após submeter, a cópia do ficheiro é automaticamente restaurada e terás o ficheiro com todas as tuas modificações que não foram ainda submetidas.

Agumas vezes você tem arquivos versionados que são alterados frequentemente mas que você de verdade não quer controlar. Algumas vezes isto indica uma falha no seu processo de desenvolvimento - por que esses arquivos são controlados? deveriam ser arquivos modelos? Mas ocasionalmente isto é inevitável. Uma razão clássica é que seu IDE muda a data/hora do arquivo em seu projeto cada vez que você compila. O arquivo do projeto tem que ser controlado já que ele inclui todas as configurações de compilação, mas você não precisa submeter apenas porque mudou a data/hora do arquivo.

Para ajudar nessas situações incomuns, nós temos uma lista de alterações específica chamada ignore-on-commit. Qualquer arquivo adicionado neste lista de alterações ficará automaticamente desmarcado na janela de submissão. Você pode ainda submeter as alterações, mas você terá que selecionar manualmente na janela de submissão.

Tenha a certeza de digitar uma mensagem de log que descreva as aterações que você está submetendo. Isto ajudará você a ver o que aconteceu e quando, ao navegador pelas mensagens de auditoria do projeto dias mais tarde. A mensagem pode ser tanto longa quanto curta; muitos projetos tem diretivas para o que será incluido, o idioma a ser usado, e algumas vezes até a formatação exigida.

Você pode formatar de forma simples sua mensagem de log usando a convenção similar ao que é usado nos e-mails. Para aplicar estilos para texto, use *texto* para negrito, _texto_ para sublinhado, e ^texto^ para itálico.

Figura 4.8. A Janela de Submissão Com Corretor Ortográfico

TortoiseSVN inclui um corretor ortográfico para lhe ajudar a escrever a sua mensagem de log corretamente. Ele irá descatar palavras erradas. Use o menu de contexto para acessar as sugestões de correção. É claro, ele não conhece todos os termos técnicos que você conhece, então palavras digitadas corretamente irão algumas vezes aparecer como erro. Mas você não deve se preocupar. Você pode simplesmente adicionar a palavra ao seu dicionário pessoal usando o menu de contexto.

The log message window also includes a filename and function auto-completion facility. This uses regular expressions to extract class and function names from the (text) files you are committing, as well as the filenames themselves. If a word you are typing matches anything in the list (after you have typed at least 3 characters, or pressed Ctrl+Space), a drop-down appears allowing you to select the full name. The regular expressions supplied with TortoiseSVN are held in the TortoiseSVN installation bin folder. You can also define your own regexes and store them in %APPDATA%\TortoiseSVN\autolist.txt. Of course your private autolist will not be overwritten when you update your installation of TortoiseSVN. If you are unfamiliar with regular expressions, take a look at the introduction at https://en.wikipedia.org/wiki/Regular_expression, and the online documentation and tutorial at http://www.regular-expressions.info/.

Conseguir a regex certa pode ser confuso, mas para ajudar você a criar uma expressão que funcione, há uma janela de testes que permite que você entre uma expressão e então digite nomes de arquivo para testar. Inicie ela da janela de comando usando o comando TortoiseProc.exe /command:autotexttest.

The log message window also includes a commit message snippet facility. These snippets are shown in the autocomplete dropdown once you type a snippet shortcut, and selecting the snippet in the autocomplete dropdown then inserts the full text of the snippet. The snippets supplied with TortoiseSVN are held in the TortoiseSVN installation bin folder. You can also define your own snippets and store them in %APPDATA%\TortoiseSVN\snippet.txt. # is the comment character. Newlines can be inserted by escaping them like this: \n and \r. To insert a backslash, escape it like this: \\.

Voce pode reutilizar mensagens já digitados. Apenas clique sobre Mensagens recentes para ver a lista das últimas mensagens digitas para a cópia de trabalho. O número de mensagens gravadas pode ser configurado na janela de configurações do TortoiseSVN.

Você pode apagar as mensagens de submissão gravadas usando a tela Dados salvos das configurações do TortoiseSVN, ou você pode apagar as mensagens uma a uma usnado a janela Mensagens recentes usando a tecla Delete.

Se você quer incluir os caminhos verificados em sua mensagem de log, você pode usar o comando Menu de Contexto → Colar lista de nomes de arquivos no campo da mensagem.

Outra forma de inserir caminhos em uma mensagem de auditoria é simplesmente arrastas os arquivos da lista de arquivos para dentro do campo da mensagem.

Depois de pressionar OK, a janela aparece mostrando o progresso da submissão.

Figura 4.9. A janela de Progresso mostra uma submissão em progresso

A janela de progresso usa cores por código para destacar diferentes ações de submissão

Este é o esquema padrão de cores, mas você pode personalizar as cores usando a janela de configurações. Acesse “Configurações de Cores do TortoiseSVN” para mais informações.

A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:

<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
      

Also, for every conflicted file Subversion places three additional files in your directory:

Podes lançar uma ferramenta externa de integração/ editor de conflitos com TortoiseSVN → Editar Conflitos ou poderás utilizar um qualquer editor de texto para resolver o conflito manualmente. Deverás decidir como é que irá ficar o código, efectua as alterações necessárias e guarda o ficheiro. Usando uma ferramenta de integração como o TortoiseMerge ou uma das outras ferramentas populares, é na generalidade a opção mais fácil já que apresentam na generalidade os ficheiros envolvidos numa painel de 3 vistas e não têm de se preocupar com os marcadores de conflitos. Se usares um editor de ficheiro terás então de pesquisar por linhas começadas pela string <<<<<<<.

Em seguida execute o comando TortoiseSVN → Resolvido e submeta suas modificações no repositório. Por favor, note que o comando Resolver não resolve o conflito. Ele apenas remove os arquivos filename.ext.mine e filename.ext.r*, para permitir que você submeta suas modificações.

Se tiver conflitos com arquivos binários, Subversion não irá incluir esses arquivos (propriamente dito). A cópia local permanece inalterada (exatamente como a modificação mais recente) e você terá arquivos filename.ext.r*. Se desejar descartar as modificações e manter a versão do repositório, apenas utilize o comando Reverter. Se desejar manter sua versão e sobreescrever o repositório, utilize o comando Resolvido e submeta sua versão.

Você pode utilizar o comando Resolvido para múltiplos arquivos se clicar com o botão direito do mouse na pasta que contém os arquivos e selecionar TortoiseSVN → Resolvido... Isto fará aparecer uma caixa de diálogo de todos os arquivos em conflito naquela pasta e então poderá selecionar quais deverão ser assinalados como resolvido.

Um conflito de propriedade acontece quando dois ou mais desenvolvedores mudaram a mesma propriedade. Assim como para o conteúdo, resolver conflitos pode ser feito apenas pelos desenvolvedores.

Se uma das alterações deve sobreescrever outra então escolha a opção Resolver usando a propriedade local ou a opção Resolver usando a propriedade remota. Se as alterações devem ser combinadas então selecione Editar a propriedade manualmente, altere o valor da propridade como ela deve ser e marque como resolvido.

Um conflito de estrutura ocorre quando um desenvolvedor move/renomeia/elimina um arquivo ou uma pasta que outro desenvolvedor tenha também movido/renomeado/eliminado ou ainda apenas modificado. Existem diversas situações que podem resultar num conflito de estrutura e cada situação exigirá uma ação diferente para a solução do conflito.

Quando um arquivo é eliminado localmente na Subversão, o arquivo também é eliminado do sistema local de arquivos ou seja, mesmo que seja parte do conflito de estrutura isso não comprova ser uma sobreposição de conflito e você não poderá clicar nele com o botão direito do mouse, para resolver o conflito. Utilize a caixa de diálogo Verificar por Modificações ao invés de acessar a opção Editar conflitos.

TortoiseSVN pode auxiliar para encontrar o lugar correto para aplicar modificações mas poderão existir tarefas adicionais e requeridas para a solução de conflitos. Lembre-se que após uma atualização, a BASE de trabalho sempre conterá a revisão de cada item tal como era no repositório no momento da atualização. Se você reverter uma modificação após uma atualização, o repositório não retornará ao estado original, tal como era antes das modificações que você iniciou localmente.

Figura 4.11. Explorer mostra os ícones sobrepostos

Agora que você obteve uma cópia de trabalho do repositório Subversion você pode ver seus arquivos no windows explorer com ícones modificados. Esta é uma das razões para que o TortoiseSVN seja tão popular. O TortoiseSVN adiciona um ícone de revestimento sobre o ícone de cada arquivo. Dependendo do status do arquivo no Subversion o revestimento é diferente.

Uma cópia de trabalho recém obtida possui uma camada contendo uma marca verde. Isto significa que o estado é normal.

Assim que você começar a editar um arquivo, o estado muda para modificado e a camada de revestimento então muda para um ponto de exclamação vermelho. Dessa maneira você pode facilmente ver quais arquivos foram alterados desde que você atualizou sua cópia de trabalho e que precisam ser submetidos.

Se durante uma atualização ocorrer um conflito então o ícone muda para um ponto de exclamação amarelo.

Se você marcou a propriedade svn:needs-lock em um arquivo, o Subversion faz com que aquele arquivo se torne somente-leitura até que você obtenha uma trava naquele arquivo. Tais arquivos tem este revestimento para indicar que você precisa obter uma trava antes que você possa editar aquele arquivo.

Se você mantém uma trava em um arquivo, e o estado do Subversion é normal, o revestimento do ícone lembra você de que você deve liberar a trava se não estiver usando-o para permitir que outros possam submeter suas mudanças para quele arquivo.

Este ícone mostra a você que alguns arquivos ou pastas dentro da pasta atual foram agendados para serem deletados do controle de versionamento ou um arquivo dentro do controle de versionamento está faltando em uma pasta.

O sinal de mais significa que um arquivo ou pasta foi agendado para ser addicionado ao controle de versões.

O sinal de barra lhe diz que um arquivo ou pasta é ignorado do controle de versões. Esse revestimento é opcional.

Este ícone mostra arquivos e pastas que não estão sob o controle de versionamento, mas não foram ignorados. Este revestimento é opcional.

De fato, você pode descobrir que nem todos estes ícones são usados em seu sistema. Isto é porque o número de camadas permitidas pelo Windows é bem limitado e se você também estiver usando uma versão antiga do TortoiseCVS, então não haverá espaço suficiente. O TortoiseSVN tenta ser um “Good Citizen (TM) - Bom Cidadão” e limita seu uso de camadas para dar outros aplicativos uma chance também.

Agora que existem vários clientes Tortoise (TortoiseCVS, TortoiseHg, ...) a limitação do ícone torna-se um problema real. Para contornar isso, o projecto TortoiseSVN introduziu um conjunto de ícones comuns e partilhados, carregados como uma DLL, que podem ser usados por todos os clientes Tortoise. Verifique com o seu provedor de cliente para ver se isso já foi integrado :-)

Para uma descrição de como as camadas de ícones correspondem ao estado do Subversion e outros detalhes técnicos, leia “Sobreposição dos Ícones”.

Figura 4.12. Página de propriedade do explorador, aba do Subversion

Algumas vezes você quer ter informações mais detalhadas sobre um arquivo/diretório do que a sobreposição de ícones. Você pode obter toda a informação que Subversion provê na janela de propriedades no explorer. Apenas selecione o arquivo ou diretório e selecione Menu do Windows → propriedades no menu de contexto (nota: esta é a entrada de menu de propriedades do explorer, não o submenu do TortoiseSVN!). No caixa de propriedades da janela, o TortoiseSVN adicionou uma nova página de propriedades para arquivos/pastas sobre o controle do Subersion, onde você pode ver todas as informações relevantes sobre os arquivos/diretórios selecionados.

Figura 4.13. Procurar por Modificações

É frequentemente muito útil saber quais arquivos você alterou e também quais arquivos foram alterados e submetidos por outros. É aí que o comando TortoiseSVN → Verificar por Modificações... se torna útil. Esta janela lhe mostrará cada arquivo que foi alterado de qualquer maneira dentro da sua cópia de tabalho, assim como quaisquer arquivos não-versionados que você possa possuir.

Se você clicar no botão Verificar Repositório então você também pode olhar as mudanças no repositório. Dessa maneira você pode checar antes de uma atualização se pode haver um possível conflito. Você também pode atualizar arquivos selecionados do repositório sem atualizar toda a pasta. Por padrão, o botão Verificar Repositório somente busca o estado remoto com a profundidade de obtenção da sua cópia de trabalho. Se você deseja ver todos os arquivos e pastas no repositório, mesmo aquelas que você não obteve, então você deve manter pressionada a tecla Shift quando clicar no botão Verificar Repositório.

A janela usa codificação de cores para demarcar o estado.

Este é o esquema padrão de cores, mas você pode personalizar as cores usando a janela de configurações. Acesse “Configurações de Cores do TortoiseSVN” para mais informações.

Ícones de sobreposição são usados para indicar também outros estados. A captura de ecrã abaixo mostra todas as sobreposições possíveis que poderão ser mostradas se necessário.

São mostradas sobreposições para os seguintes estados:

Itens que foram trocados para um caminho diferente no repositório são também sinalizados com um marcador (s). Podes ter trocado algo enquanto trabalhavas num ramo e te esqueceste de trocar de novo para o trunk. Isto é o teu sinal de aviso! O menu de contexto permite-te trocar de volta para o caminho normal mas uma vez.

Do menu de contexto da janela você pode ver um diff de mudanças. Marque as mudanças localis que você fez usando Menu de Contexto → Comparar com Base. Marque as mudanças no repositório feitas por outros usando Menu de Contexto → Mostrar Diferenças como Diff Unificado.

Você também pode reverter as mudanças em arquivos individuais. Se você apagou um arquivo acidentalmente, ele aparecerá como Faltando e você pode usar Reverter para recuperá-lo.

Arquivos não-versionados e ignorados podem ser enviados para a lixeira daqui usando Menu de Contexto → Apagar. Se você deseja apagar arquivos permanentemente (ignorando a lixeira) matenha pressionada a tecla Shift enquanto cliclar em Apagar.

Se tu quiseres examinar um ficheiro em detalhe, podes arrastá-lo daqui para outro aplicativo, como um editor de texto ou IDE, ou podes salvar uma cópia simplesmente arrastando-o para uma pasta do navegador.

As colunas são personalizáveis. Se você clicar com o botão direito em qualquer cabeçalho de coluna você verá um menu de contexto permitindo-o selecionar quais colunas serão exibidas. Você pode também alterar a largura das colunas usando o ícone de arrastar que aparece quando você passa o mouse em cima de uma borda de coluna. Essas personalizações são preservadas, então você verá os mesmos cabeçalhos da próxima vez.

Se você está trabalhando em diversas tarefas independentes ao mesmo tempo, você pode também agrupar arquivos em changelists. Leia “Lista de Alterações” para maiores informações.

Na parte inferior da janela você pode ver um sumário da variação das revisões do repositório em uso na sua cópia de trabalho. Essas são as revisões submetidas, não as revisões atualizadas; elas representam a variação das revisões onde estes arquivos foram submetidos pela última vez, não as revisões nas quais foram atualizados. Note que a variação de revisões mostrada aplica-se somente aos itens exibidos, não à cópia de trabalho inteira. Se você deseja ver informações sobre a cópia de trabalho inteira você deve marcar a caixa Mostrar arquivos não modificados.

Frequentemente você deseja olhar dentro de seus arquivos, para observar o que foi alterado. Você pode fazê-lo selecionando o arquivo que foi alterado, e selecionando Diff do menu de contexto do TortoiseSVN. Isto inicia o visualizador-diff externo, que irá então comparar o arquivo atual com a cópia pristina ( revisão BASE), que foi armazenada após a última submissão ou atualização.

Figura 4.17. A Janela de Histórico de Revisão

There are several places from where you can show the Log dialog:

Se o repositório está indisponível você verá a janela Deseja continuar desconectado?, descrito em “Modo desconectado”.

o painel superior tem uma coluna Ações contendo ícones que resumem o que foi feito na revisão. Existem quatro diferentes ícones, cada um apresentado na sua própria coluna.

Se uma revisão modificou algum arquivo ou diretório, o ícone modificado é apresentado na primeira coluna.

Se uma revisão adicionou algum arquivo ou diretório, o ícone adicionado é apresentado na segunda coluna.

Se uma revisão apagou algum arquivo ou diretório, o ícone apagado é apresentado na terceira coluna.

Se uma revisão sobrepôs algum arquivo ou diretório, o ícone substituído é apresentado na quarta coluna.

If a revision moved or renamed a file or directory, the moved icon is shown in the fourth column.

If a revision replaced a file or directory by moving/renaming it, the move replaced icon is shown in the fourth column.

If a revision merged a file or directory, the merged icon is shown in the fourth column.

If a revision reverse merged a file or directory, the reverse merged icon is shown in the fourth column.

Figura 4.18. O Menu de Contexto do Painel Superior da Janela de Auditoria da Revisão

The top pane of the Log dialog has a context menu that allows you to access much more information. Some of these menu entries appear only when the log is shown for a file, and some only when the log is shown for a folder.

Figura 4.19. A Janela de Configurações do Colaborador de Código

Figura 4.20. Menu de Contexto do Painel Superior para 2 Revisões Selecionadas

Se você selecionar duas revisões de uma vez (usando o comum Ctrl-modificador), o menu de contexto mudará e mostrará algumas opções adicionais:

Se você selecionar duas ou mais revisões (usando os modificadores Ctrl ou Shift), o menu de contexto irá incluir uma entrada para Reverter todas as mudanças que foram reitas pelas revisões selecionadas. Esta é a maneira mais fácil de restaurar um grupo de revisões de uma vez.

Você pode também escolher combinar as revisões selecionadas para outra cópia de trabalho, como descrito acima.

Se todas as revisões selecionadas são do mesmo autor, você pode editar o autor de todas as revisões de uma vez só.

Figura 4.21. O Painel Inferior da Janela de Auditoria com Menu de Contexto

The bottom pane of the Log dialog also has a context menu that allows you to

When multiple files are selected in the bottom pane of the Log dialog, the context menu changes to the following:

Figura 4.22. The Log Dialog Bottom Pane with Context Menu When Multiple Files Selected.

A caixa de diálogo Log nem sempre motra todas as alterações já feitas por uma série de motivos:

Se você quer ver mais mensagens de log, clique no Próximos 100 para recuperar as próximas 100 mensagens de log. Você pode repetir isso quantas vezes for preciso.

Próximo a este botão existe um botão multi-funcional que lembra a última opção que você usou. Clique na seta para ver as outras opções fornecidas.

Use Mostrar Faixa ... se você quiser ver uma faixa de revisões específica. Uma janela irá pedir que você entre as revisões inicial e final.

Use Mostrar Todas se você quiser ver todas as mensagens de log de HEAD até a revisão 1.

Para atualizar as últimas revisões no caso de terem havido outros commits enquanto a caixa de diálogo de log esteve aberta, pressione a tecla F5.

Para atualizar o chache de log, pressione as teclas Ctrl-F5.

Como a janela de log mostra o log de HEAD, não da revisão da cópia de trabalho atual, é comum que haja mensagens de log para conteúdo que ainda não foi atualizado na cópia de trabalho. Para ajudar a deixar isto mais claro, a mensagem de submissão que corresponde à revisão que você têm na sua cópia de trabalho é mostrada em negrito.

Quando você exibe o log para uma pasta, a revisão destacada é a maior revisão encontrada dentro daquela pasta, o que requer uma pesquisa da cópia de trabalho. A pesquisa é realizada em um processo separado para não demorar para mostrar o log, mas com isso, o destaque de pastas pode não aparecer imediatamente.

Subversion 1.5 e posteriores mantém um registro das combinações usando propriedades. Isto permite que nós tenhamos um histórico mais detalhado das mudanças combinadas. Por exemplo, se você deselvolve um novo recurso em um ramo e então combina este ramo de volta com o tronco, o desenvolvimento do recurso será mostrado no log do tronco como uma única submissão para a combinação, mesmo que possa haver 1000 submissões durante o desenvolvimento no ramo.

Figura 4.23. A Janela de Auditoria Mostrando as Revisões de Rastreamento de Combinação

Se você quiser ver os detalhes de quais revisões foram combinadas como parte da submissão, use a caixa de marcar Incluir revisões combinadas. Isto irá obter as mensagens de log novamente, mas também irá intercalar as mensagens de log das revisões que foram combinadas. revisões combinadas são mostradas em cinza porquê representam mudanças feiras em partes diferentes da árvore.

É claro que combinar nunca é simples! Durante o desenvolvimento de um recurso no ramo, provavelmente irão ocorrer combinações com o tronco para manter o ramo sincronizado com a linha de código principal. Então o histórico de combinações do ramo também irá mostrar outra camada de histórico de combinações. Estas camadas diferentes são mostradas na janela de log usando níveis de indentação.

Propriedades de revisão são completamente diferentes das propriedades da Subversion de cada item. Propriedades de revisão são itens descritivos que são associados com um número de revisão específico no repositório, como uma mensagem de log, data de submissão e nome do autor.

Algumas vezes você pode querer mudar uma mensagem de log que você entrou, talvez porque há erros ou porque você quer melhorar a mensagem ou mudá-la por outras razões. Ou você quer mudar o autor da submissão porque você esqueceu de configurar a autenticação ou...

Subversion lets you change revision properties any time you want. But since such changes can't be undone (those changes are not versioned) this feature is disabled by default. To make this work, you must set up a pre-revprop-change hook. Please refer to the chapter on Hook Scripts in the Subversion Book for details about how to do that. Read “Rotinas de eventos no servidor” to find some further notes on implementing hooks on a Windows machine.

Uma vêz que você já configurou seu servidor com os hooks necessários, você pode mudar o autor e a mensagem de log (ou qualquer outra propriedade de revisão) de qulquer revisão, usando o menu de contexto do painel superior da janela de Log. Você também pode editar uma mensagem de log usando o menu de contexto do painel do meio.

Se você quiser restringir as mensagen de log para mostrar apenas às que você está interessado ao invés de rolar por toda a lista de milhares, você pode usar os controles de filtro no topo da Janela de Log. Os controles de datas inicial e final permitem que você restrinja a saída à uma faixa de datas conhecida. A caixa de busca permite que você mostre apenas as mensagens que contenham uma frase particular.

Clique no ícone de busca para selecionar a informação na qual você quer pesquisar e escolha o modo regex. Normalmente você irá precisar apenas de uma busca simples de palavras, mas se você precisar de termos de busca mais flexíveis, você pode usar expressões regulares. Se você colocar o curosor sobre a caixa, uma dica de tela irá dar dicas de como usar funções de expressões regulares. O filtro funciona checando quando o texto do filtro combina com as entradas de log, e então apenas estas entradas que combinam com o filtro são exibidas.

Simple sub-string search works in a manner similar to a search engine. Strings to search for are separated by spaces, and all strings must match. You can use a leading - to specify that a particular sub-string is not found (invert matching for that term), and you can use ! at the start of the expression to invert matching for the entire expression. You can use a leading + to specify that a sub-string should be included, even if previously excluded with a -. Note that the order of inclusion/exclusion is significant here. You can use quote marks to surround a string which must contain spaces, and if you want to search for a literal quotation mark you can use two quotation marks together as a self-escaping sequence. Note that the backslash character is not used as an escape character and has no special significance in simple sub-string searches. Examples will make this easier:

Alice Bob -Eve
      

searches for strings containing both Alice and Bob but not Eve

Alice -Bob +Eve
      

searches for strings containing both Alice but not Bob, or strings which contain Eve.

-Case +SpecialCase
      

searches for strings which do not contain Case, but still include strings which contain SpecialCase.

!Alice Bob
      

searches for strings which do not contain both Alice and Bob

!-Alice -Bob
      

do you remember De Morgan's theorem? NOT(NOT Alice AND NOT Bob) reduces to (Alice OR Bob).

"Alice and Bob"
      

searches for the literal expression “Alice and Bob”

""
      

searches for a double-quote anywhere in the text

"Alice says ""hi"" to Bob"
      

searches for the literal expression “Alice says "hi" to Bob”.

Descrever o uso de expressões regulares está além do escopo deste manual, mas você pode encontrar documentações online e um tutorial em http://www.regular-expressions.info/.

Note que estes filtros atuam nas mensagens já recuperadas. Eles não controlam a recuperação das mensagens do repositório.

Você também pode filtrar os nomes de caminho no painel de baixo usando a caixa Mostrar apenas caminhos afetados. Caminhos afetados são os que contém o caminho usado para mostrar o log. Se você obter o log para uma pasta, isto significa qualquer coisa na pasta ou abaixo dela. Para um arquivo, isto significa apenas aquele arquivo. Normalmente a lista de caminhos mostra quaisquer outros caminhos que são afetados pela mesma submissão, mas em cinza. Se a caixa é marcada, estes caminhos são ocultos.

Algumas vezes suas práticas de trabalho irão precisar que as mensagens de log sigam um formato particular, o que significa que o texto descrevendo as mudanças não é visível no resumo abreviado que é exibido no painel superior. A propriedade tsvn:logsummary pode ser usada para extrair uma parte da mensagem de log para ser exibida no painel superior. Leia “Propriedades do Projeto TortoiseSVN” para saber como usar esta propriedade.

O botão Estatísticas tráz uma caixa exibindo algumas informações interessantes sobre as revisões mostradas na janela de Log. Isto mostra quantos autores trabalharam, quantas submissões eles fizeram, progresso por semana, e muito mais. Agora você pode ter um relance de quem tem trabalhado duro e quem está enrolando ;-)

Submissões por Página do Autor

Figura 4.24. Histograma de Submissões-por-autor

Este gráfico mostra a você quais autores têm estado ativos no projeto com um histograma simples, histograma de barras ou gráfico de pizza.

Figura 4.25. Gráfico de Pizza das Submissões-por-Autor

Quando houver poucos autores principais e muitos contribuintes menores, o número de segmentos pequenos pode fazer o gráfico mais difícil de ler. O controle deslizante abaixo permite que você ajuste um limite (como uma porcentagem do total de submissões) abaixo do qual qualquer atividade é agrupada na categoria Outros.

Submissões por Página de Data

Figura 4.26. Gráfico de Submissões-por-data

Esta página dá a você uma representação gráfica da atividade do projeto em termos de número de submissões e autor. Isso dá alguma ideia de quando um projeto está sendo trabalhado e quem estava trabalhando em que tempo.

Quando existem vários autores, você verá muitas linhas no gráfico. Existem duas visões disponíveis aqui: normal, onde a atividade de cada autor é relativa à linha de base, e compactado, onde a atividade de cada autor é relativa à linha de baixo. A última opção evita linhas cruzadas, a qual permite uma gráfico mais fácil de ser lido, porém mais difícil de visualizar as informações de um único autor.

Por padrão a analise é case-sensitive, portanto usuários como PeterEgan e PeteRegan são considerados autores diferentes. Entretanto, em muitos casos os nomes de usuários não são case-sensitive, e às vezes são inseridos de forma inconsistente, então você pode querer que DavidMorgan e davidmorgan sejam considerados a mesma pessoa. Use a seleção Authors case insensitive para escolher como lidar com isso.

Observe que as estatísticas cobrem o mesmo período que o diálogo de Log. Se este está mostrando apenas uma revisão então as estatísticas não irão informar muito.

Figura 4.27. Ir para Janela de Desconectado

Se o servidor não está acessível, e você tem o habilitar o cache de log, você pode usar a caixa de diálogo e gráfico de revisão no modo offline. Este usa dados do cache, o que lhe permite continuar a trabalhar, embora a informação não possa ser atualizada ou mesmo completada.

Aqui você tem três opções:

A caixa de opção Torne isto o padrão previne que este diálogo reapareça e sempre seleciona a próxima opção que você escolher. Você ainda pode mudar (ou remover) o padrão depois de fazer isso em TortoiseSVN → Configurações.

Se você quiser verificar novamente o servidor por novas mensagens de auditoria, você pode simplesmente atualizar a visualização usando F5. Se você estiver usando o cache de auditoria (habilitado por padrão), isto irá verificar o repositório por mensagens mais novas e buscar apenas as novas. Se o cache de auditoria estiver em modo desativado, isto também tentará colocá-lo em modo disponível.

Se você estiver usando o cache de auditoria e achar que o conteúdo ou o autor da mensagem mudou, você pode usar Shift-F5 ou Ctrl-F5 para buscar novamente do servidor as mensagens apresentadas e atualizar o cache de auditoria. Note que isto afeta apenas as mensagens atualmente mostradas e não invalida inteiramente o cache deste repositório.

If you have configured a third party diff tool, you can use Shift when selecting the Diff command to use the alternate tool. Read “Configuração de Programa Externo” to find out about configuring other diff tools.

Sometimes in the life of a project you might change the line endings from CRLF to LF, or you may change the indentation of a section. Unfortunately this will mark a large number of lines as changed, even though there is no change to the meaning of the code. The options here will help to manage these changes when it comes to comparing and applying differences. You will see these settings in the Merge and Blame dialogs, as well as in the settings for TortoiseMerge.

Ignorar fim de linha exclui alterações que são exclusivamente ara diferenciar o identificador de fim de linha.

Comparar espaços em branco inlcui todas as alterações de indentação e espaços em branco como linhas adicionadas/removidas.

Ignore whitespace changes excludes changes which are due solely to a change in the amount or type of whitespace, e.g. changing the indentation or changing tabs to spaces. Adding whitespace where there was none before, or removing a whitespace completely is still shown as a change.

Ignorar todos os espaços em branco exclui todas as mudanças que são apenas espaços em branco.

Naturalmente, qualquer linha com conteúdo alterado é sempre incluída na diferenciação.

Figura 4.28. A Janela de Comparação de Revisões

When you select two trees within the repository browser, or when you select two revisions of a folder in the log dialog, you can Context menu → Compare revisions.

Esta janela mostra a lista de todos os arquivos que sofreram alteração e permite a você comparar ou identificar seu autor individualmente usando o menu de contexto.

You can export a change tree, which is useful if you need to send someone else your project tree structure, but containing only the files which have changed. This operation works on the selected files only, so you need to select the files of interest - usually that means all of them - and then Context menu → Export selection to.... You will be prompted for a location to save the change tree.

Você pode também exportar a lista de arquivos alterados para um arquivo texto usando Menu de contexto → Salvar lista de arquivos selecionados para....

Se você quer exportar a lista de arquivos e também as ações (modificado, adicionado, apagado), você pode fazê-lo usando Menu de contexto → Copiar seleção para área de transferência.

O botão no topo permite a você mudar a direção da comparação. Você pode mostrar as alterações realizadas de A para B, ou se você preferir, de B para A.

Os botões contendo os números de revisão podem ser usados para mudar para uma faixa de revisão diferente. Quando você mudar a faixa, a lista de itens os quais diferem em duas revisões serão automaticamente atualizados.

Se a lista de arquivos é muito extensa, você pode usar a caixa de busca para reduzir a lista de nomes de arquivos para apenas os que contém o texto específico. Note que uma busca por texto simples é usada, então se você quer restringir a lista de arquivos para código em C você deve digitar .c ao invés de *.c.

Existem muitas ferramentas disponíveis para comparar arquivos texto, incluindo nosso próprio TortoiseMerge, porém nós frequentemente nos pegamos querendo ver as modificações em uma imagem além de somente textos. Por isso nós criamos o TortoiseIDiff.

Figura 4.29. O visualizar de diferenças de imagem

TortoiseSVN → Diff for any of the common image file formats will start TortoiseIDiff to show image differences. By default the images are displayed side-by-side but you can use the View menu or toolbar to switch to a top-bottom view instead, or if you prefer, you can overlay the images and pretend you are using a lightbox.

Naturally you can also zoom in and out and pan around the image. You can also pan the image simply by left-dragging it. If you select the Link images together option, then the pan controls (scrollbars, mousewheel) on both images are linked.

Uma caixa de informação de imagem mostra os detalhes sobre a mesma, como o tamanho em píxeis, resolução e nível de cor. Se esta caixa está a atrapalhar usa View → Image Info para a esconder. Podes obter a mesma informação numa etiqueta, se mantiveres o rato sobre a barra de título da imagem.

When the images are overlaid, the relative intensity of the images (alpha blend) is controlled by a slider control at the left side. You can click anywhere in the slider to set the blend directly, or you can drag the slider to change the blend interactively. Ctrl+Shift-Wheel to change the blend.

The button above the slider toggles between 0% and 100% blends, and if you double click the button, the blend toggles automatically every second until you click the button again. This can be useful when looking for multiple small changes.

Sometimes you want to see a difference rather than a blend. You might have the image files for two revisions of a printed circuit board and want to see which tracks have changed. If you disable alpha blend mode, the difference will be shown as an XOR of the pixel colour values. Unchanged areas will be plain white and changes will be coloured.

Quando queres comparar documentos não-textuais normalmente terás de utilizar o software usado para criar o documento, já que ele entende o formato do ficheiro.Para as suites do Microsoft Office e Open Office, normalmente usadas, existe realmente algum suporte para a visualização das diferenças e o TortoiseSVN inclui scripts para os invocar com as definições correctas ao comparar ficheiros com essas extensões bem conhecidas. Podes verificar que extensões de ficheiros são suportadas e adicionar a tua própria indo à secção TortoiseSVN → Definições e clicar Avançado em Programas Externos

Se as ferramentas providas por nós não faz o que você precisa, tente uma das muitas disponíveis de código aberto ou comerciais. Todo mundo tem suas favoritas, e esta lista não tem o propósito de estar completa, mas aqui estão algumas que nós devemos consideramos:

Leia “Configuração de Programa Externo” para mais informações sobre como configurar o TortoiseSVN para usar essas ferramentas.

Os padrões para ingorar arquivos do Subversion fazem uso do nome de arquivo global, uma técnica originalmente usada no Unix para especificar arquivos usando meta-caracteres como coringas. Os caracteres a seguir tem um significado especial:

Pattern matching is case sensitive, which can cause problems on Windows. You can force case insensitivity the hard way by pairing characters, e.g. to ignore *.tmp regardless of case, you could use a pattern like *.[Tt][Mm][Pp].

Se você quer uma definição oficial para nomes de arquivos globais, você pode encontrar nas especificações IEEE para linguagem de comando de integração Pattern Matching Notation.

Para remover ficheiros ou pastas do Subversion usa TortoiseSVN → Remover.

Quando TortoiseSVNRemover

Se você quer apagar um item do repositório, mas manter uma versão local não versionada do arquivo/diretório, use Menu de Contexto Estendido → Excluir (manter local). Você deve manter a tecla Shift pressionada enquando clica com o botão direito no item desejado no painel direito do "explorer" para ver este menu de contexto estendido.

If an item is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those items as missing and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing item and replace it with the latest version from the repository. If you need to delete a version-controlled file, always use TortoiseSVN → Delete so that Subversion doesn't have to guess what you really want to do.

Se você quer fazer uma simples renomeação de arquivo ou diretório, use Menu de Contexto → Renomear... e entre com o novo nome para o item e estará feito.

If you want to move files around inside your working copy, perhaps to a different sub-folder, use the right mouse drag-and-drop handler:

Another way of moving or copying files is to use the Windows copy/cut commands. Select the files you want to copy, right click and choose Context Menu → Copy from the explorer context menu. Then browse to the target folder, right click and choose TortoiseSVN → Paste. For moving files, choose Context Menu → Cut instead of Context Menu → Copy.

Você pode também usar o navegador de repositório para mover itens. Leia “O Navegador de Repositório” para descobrir mais.

Se o repositório atualmente já contém dois arquivos com o mesmo nome diferenciados apenas pela caixa (exemplo: TEST.TXT e test.txt, você não poderá atualizar ou obter o diretório em um cliente Windows.Embora o Subversion suporte diferenciação na caixa no nome dos arquivos, o Windows não suporta.

Isto algumas vezes acontece quando duas pessoas submetem, de diferentes cópias de trabalho, arquivos salvos com o mesmo nome, mas com caixa diferente. Isto pode também acontecer quando os arquivos forem submetidos de um sistema de arquivos que trata a caixa do nome dos arquivos, como Linux.

Nestes casos, você precisa decidir qual dos arquivos você quer manter e então apagar (ou renomear) o outro arquivo no repositório.

Algumas vezes seu amigável IDE vai renomear arquivos para você como parte de uma refatoração, e é claro isto não é o Subversion. Se você tentar submeter suas alterações, Subversion verá que há velhos arquivos perdidos e que há novos arquivos não controlados. Você poderá apenas verificar o novo nome para adicioná-lo, mas você então perderá o histórico, já que o Subversion não conhece a relação dos arquivos.

Uma maneira melhor de notificar o Subversion é identificar a alteração como uma renomeação, e você pode fazer isso usando as janelas de Submeter e Verificar alterações. Apenas selecione ambos os arquivos (perdido e não controlado) e use Menu de Contexto → Reparar movimento para identificar os dois arquivos como uma renomeação.

Normalmente você define sua lista de arquivos ignorados para que todos os arquivos criados sejam ignorados pelo Subversion. Mas e se você quer remover todos os arquivos ignorados para produzir uma compilação limpa? Normalmente você definie isso no arquivo makefile, mas e se você está depurando o arquivo makefile, ou alterando o sistema de compilação é útil ter uma forma de limpar tudo.

TortoiseSVN provê justamente uma opção usando Menu de Contexto Estendido → Apagar arquivos não controlados.... VocShift enquando clica o bot

Quando tais arquivos são removidos, a lixeira é usada, então se você cometeu algum erro ao excluir um arquivo que não estava sendo controlado, você ainda poderá restaurar o arquivo.

Figura 4.36. página de propriedades do Subversion

You can read and set the Subversion properties from the Windows properties dialog, but also from TortoiseSVN → properties and within TortoiseSVN's status lists, from Context menu → properties.

You can add your own properties, or some properties with a special meaning in Subversion. These begin with svn:. svn:externals is such a property; see how to handle externals in “Itens Externos”.

For more information about properties in Subversion see the Special Properties.

Adicionando e Editando Propriedades

Figura 4.37. Adicionando propriedades

To add a new property, first click on New.... Select the required property name from the menu, and then fill in the required information in the specific property dialog. These specific property dialogs are described in more detail in “Editores de Propriedades”.

To add a property that doesn't have its own dialog, choose Advanced from the New... menu. Then either select an existing property in the combo box or enter a custom property name.

If you want to apply a property to many items at once, select the files/folders in explorer, then select Context menu → properties.

Se deseja aplicar a propriedade para todos os arquivos e diretórios na hierarquia abaixo do diretório atual, marque a opção Recursivo .

Se deseja editar uma propriedade existente, selecione a propriedade da lista de propriedades existentes e então clique em Editar....

Se deseja editar uma propriedade existente, selecione a propriedade da lista de propriedades existentes e então clique em Remover.

A propriedade svn:externals pode ser usada para enviar outros projetos para o mesmo repositório ou para um repositório completamente diferente. Para maiores informações, leia “Itens Externos”.

Editar propriedades na revisão atual

Pelo fato das propriedades serem versionadas, não é possível editar as revisões anteriores. Se verificar as propriedades pela caixa de dialogo do log, ou por uma revisão no navegador do repositório que não seja a ultima, poderá visualizar a lista de propriedades e valores, porem não terá nenhum controle de edição disponível.

TortoiseSVN tem algumas propriedades especiais próprias, que começam com tsvn:.

TortoiseSVN can integrate with some bug tracking tools. This uses project properties that start with bugtraq:. Read “Integração com Sistemas de Rastreamento de Erros / Rastreadores de Reportes” for further information.

It can also integrate with some web-based repository browsers, using project properties that start with webviewer:. Read “Integração com visualizadores de repositórios locados na web” for further information.

When you add new sub-folders to a working copy using TortoiseSVN, any project properties present in the parent folder will automatically be added to the new child folder too.

Some properties have to use specific values, or be formatted in a specific way in order to be used for automation. To help get the formatting correct, TortoiseSVN presents edit dialogs for some particular properties which show the possible values or break the property into its individual components.

Conteúdo Externo

Figura 4.40. página da propriedade svn:externals

The svn:externals property can be used to pull in other projects from the same repository or a completely different repository as described in “Itens Externos”.

You need to define the name of the sub-folder that the external folder is checked out as, and the Subversion URL of the external item. You can check out an external at its HEAD revision, so when the external item changes in the repository, your working copy will receive those changes on update. However, if you want the external to reference a particular stable point then you can specify the specific revision to use. IN this case you may also want to specify the same revision as a peg revision. If the external item is renamed at some point in the future then Subversion will not be able to update this item in your working copy. By specifying a peg revision you tell Subversion to look for an item that had that name at the peg revision rather than at HEAD.

The button Find HEAD-Revision fetches the HEAD revision of every external URL and shows that HEAD revision in the rightmost column. After the HEAD revision is known, a simple right click on an external gives you the command to peg the selected externals to their explicit HEAD revision. In case the HEAD revision is not known yet, the right click command will fetch the HEAD revision first.

Palavras-chave do SVN

Figura 4.41. página da propriedade svn:keywords

Seleciona as palavras-chave que você gostaria que fosse expandida em seu arquivo.

Estilo FDL

Figura 4.42. página da propriedade svn:eol-style

Seleciona o estilo de fim de linha que você deseja usar e o TortoiseSVN usará o valor da propriedade correto.

Integração para Rastreador de Reportes

Figura 4.43. página da propriedade tsvn:bugtraq

Tamanhos das Mensagens de Auditoria

Figura 4.44. Página da propriedade do tamanho das mensagens de auditoria

These 3 properties control the formatting of log messages. The first 2 disable the OK in the commit or lock dialogs until the message meets the minimum length. The border position shows a marker at the given column width as a guide for projects which have width limits on their log messages. Setting a value to zero will delete the property.

Idioma do Projeto

Figura 4.45. Página da propriedade idioma

Escolhe a linguagem a usar para verificar ortografia nas mensagens de registona caixa de diálogo submeter. A caixa de verificação de lista de ficheiros têm utilidade quando clicas à direita no painel de mensagem e seleccionas Colar lista de ficheiros. Por defeito o estado do Subversion será mostrado na lingua local. Quando esta caixa está sinalizada o estado é sempre dado em Inglês, para projectos que requerem mensagens de registo apenas em Inglês.

MIME-type

Figura 4.46. página da propriedade svn:mime-type

svn:needs-lock

Figura 4.47. página da propriedade svn:needs-lock

This property simply controls whether a file will be checked out as read-only if there is no lock held for it in the working copy.

svn:executable

Figura 4.48. página da propriedade svn:executable

This property controls whether a file will be given executable status when checked out on a Unix/Linux system. It has no effect on a Windows checkout.

Templates de mensagens de registo

Quando são integradas as revisões na cópia de trabalho, o TortoiseSVN gera uma mensagem de registo para todas as revisões integradas. Essas ficam então disponíveis a partir do botão Mensagens recentes na janela de diálogo submeter.

Você pode customizar esta mensagem gerada com as seguintes propriedades:

Figura 4.49. Caixa de propriedades integra templates de mensagens de registo

tsvn:mergelogtemplatetitle, tsvn:mergelogtemplatereversetitle

Esta propriedade especifica a primeira parte da mensagem de auditoria gerada. As seguintes palavras-chave podem ser usadas:

{revisions}

Uma lista de revisões combinadas separadas por vírgula, p.ex., 3, 5, 6, 7

{revisionsr}

Como {revisions},mas com cada revisão precedida com um r, e.g., r3, r5, r6, r7

{revrange}

Uma lista de revisões combinadas separadas por vírgula, se possível agrupadas em intervalos, p.ex., 3, 5-7

{mergeurl}

O URL fonte da integração, i.e., de onde são integradas as revisões.

O valor por defeito para esta string é Merged revision(s) {revrange} from {mergeurl}: com uma linha nova no fim.

tsvn:mergelogtemplatemsg

Esta propriedade especifica como o texto para cada revisão combinada deve se parecer. As seguintes palavras-chaves podem ser usadas:

{msg}

A mensagem de auditoria da revisão combinada, como ela foi entrada.

{msgoneline}

Como o {msg}, mas todas as linhas novas são substituídas por um espaço, para que toda a mensagem de registo apareça numa única linha.

{author}

O autor da revisão mesclada

{rev}

A própria revisão combinada.

{bugids}

Os IDs dos erros da revisão combinada, se existirem.

tsvn:mergelogtemplatemsgtitlebottom

This property specifies the position of the title string specified with the tsvn:mergelogtemplatetitle or tsvn:mergelogtemplatereversetitle. If the property is set to yes or true, then the title string is appended at the bottom instead of the top.

Importante

Isto só funciona se as revisões combinadas já estiverem no cache de auditoria. Se você tiver desabilitado o cache de auditoria ou não tiver mostrado a auditoria logo antes da combinação, a mensagem gerada não conterá quaisquer informações sobre as revisões combinadas.

Let's say you check out a working copy of /project1 to D:\dev\project1. Select the folder D:\dev\project1, right click and choose Windows Menu → Properties from the context menu. The Properties Dialog comes up. Then go to the Subversion tab. There, you can set properties. Click Properties.... In the properties dialog, either double click on the svn:externals if it already exists, or click on the New... button and select externals from the menu. To add a new external, click the New... and then fill in the required information in the shown dialog.

Se você quiser que o caminho local inclua "espaços" ou outro caracter especial, terá que incluí-lo entre aspas ou usar o caracter \ (barra invertida) como um caracter de escape, ao estilo da linha de comandos do Linux, precedendo cada caracter especial. É claro que isto também significa que terá que necessariamente usar / (barra inclinada) como delimitador de caminho. Note que este comportamento é inusitado no Subversion 1.6 e não funcionará em versões mais antigas.

Se o projeto externo está no mesmo repositório, quaisquer alterações feitas serão incluídas na lista de submissão quando submeter seu projeto principal.

If the external project is in a different repository, any changes you make to the external project will be shown or indicated when you commit the main project, but you have to commit those external changes separately.

Se usar URLs absolutas nas definições svn:externals e tiver que realocar sua cópia de trabalho (ou seja, a URL do seu repositório é alterada), então seus "externos" não serão alterados e poderão deixar de funcionar.

Para evitar tais problemas, a versão 1.5 ou superior do cliente Subversion, suporta URLs externas relativas. Quatro diferentes métodos de especificar uma URL relativa são suportados. Nos exemplos seguintes assume-se que temos dois repositórios: um em http://example.com/svn/repos-1 e outro em http://example.com/svn/repos-2. Temos um SVN exportado do http://example.com/svn/repos-1/project/trunk em C:\Working e a propriedade svn:externals está configurada no trunk.

You can also specify a peg and operative revision for the URL if required. To learn more about peg and operative revisions, please read the corresponding chapter in the Subversion book.

Caso necessite mais informações sobre como TortoiseSVN lida com "Propriedades", consulte “Configurações do Projeto”.

Para saber mais sobre diferentes métodos de acesso a subprojetos comuns, consulte “Inclua um subprojeto em comum”.

Desde a versão 1.6 do Subversion você pode incluir um único arquivo externo em sua cópia de trabalho usando a mesma sintaxe que usaria para diretórios. Entretanto existem algumas restrições.

Em vários aspectos um arquivo externo comporta-se como qualquer outro arquivo versionado, mas eles não podem ser movidos ou eliminados usando os comandos normais; é obrigatório que a propriedade svn:externals seja modificada.

If you already have a working copy of the files or folders you want to include as externals in another working copy, you can simply add those via drag and drop from the windows explorer.

Simply right drag the file or folder from one working copy to where you want those to be included as externals. A context menu appears when you release the mouse button: SVN Add as externals here if you click on that context menu entry, the svn:externals property is automatically added. All you have to do after that is commit the property changes and update to get those externals properly included in your working copy.

If you have imported your project with the recommended directory structure, creating a branch or tag version is very simple:

Figura 4.50. A Janela de Ramificação/Rotulação

Select the folder in your working copy which you want to copy to a branch or tag, then select the command TortoiseSVN → Branch/Tag....

The default destination URL for the new branch will be the source URL on which your working copy is based. You will need to edit that URL to the new path for your branch/tag. So instead of

http://svn.collab.net/repos/ProjectName/trunk
      

you might now use something like

http://svn.collab.net/repos/ProjectName/tags/Release_1.10
      

If you can't remember the naming convention you used last time, click the button on the right to open the repository browser so you can view the existing repository structure.

Agora você tem que selecionar a fonte da cópia. Aqui você tem três opções:

If you want your working copy to be switched to the newly created branch automatically, use the Switch working copy to new branch/tag checkbox. But if you do that, first make sure that your working copy does not contain modifications. If it does, those changes will be merged into the branch WC when you switch.

If your working copy has other projects included with svn:externals properties, those externals will be listed at the bottom of the branch/tag dialog. For each external, the target path and the source URL is shown.

If you want to make sure that the new tag always is in a consistent state, check all the externals to have their revisions pinned. If you don't check the externals and those externals point to a HEAD revision which might change in the future, checking out the new tag will check out that HEAD revision of the external and your tag might not compile anymore. So it's always a good idea to set the externals to an explicit revision when creating a tag.

The externals are automatically pinned to either the current HEAD revision or the working copy BASE revision, depending on the source of the branch/tag:

Press OK to commit the new copy to the repository. Don't forget to supply a log message. Note that the copy is created inside the repository.

Note that unless you opted to switch your working copy to the newly created branch, creating a Branch or Tag does not affect your working copy. Even if you create the branch from your WC, those changes are committed to the new branch, not to the trunk, so your WC may still be marked as modified with respect to the trunk.

You can also create a branch or tag without having a working copy. To do that, open the repository browser. You can there drag folders to a new location. You have to hold down the Ctrl key while you drag to create a copy, otherwise the folder gets moved, not copied.

You can also drag a folder with the right mouse button. Once you release the mouse button you can choose from the context menu whether you want the folder to be moved or copied. Of course to create a branch or tag you must copy the folder, not move it.

Yet another way is from the log dialog. You can show the log dialog for e.g. trunk, select a revision (either the HEAD revision at the very top or an earlier revision), right click and choose create branch/tag from revision....

...that is (not really) the question. While a checkout downloads everything from the desired branch in the repository to your working directory, TortoiseSVN → Switch... only transfers the changed data to your working copy. Good for the network load, good for your patience. :-)

To be able to work with your freshly generated branch or tag you have several ways to handle it. You can:

Figura 4.51. A Janela de Troca

Although Subversion itself makes no distinction between tags and branches, the way they are typically used differs a bit.

Figura 4.52. O Assistente de Combinação - Selecionar Faixa de Revisões

In the From: field enter the full folder URL of the branch or tag containing the changes you want to port into your working copy. You may also click ... to browse the repository and find the desired branch. If you have merged from this branch before, then just use the drop down list which shows a history of previously used URLs.

If you are merging from a renamed or deleted branch then you will have to go back to a revision where that branch still existed. In this case you will also need to specify that revision as a peg revision in the range of revisions being merged (see below), otherwise the merge will fail when it can't find that path at HEAD.

In the Revision range to merge field enter the list of revisions you want to merge. This can be a single revision, a list of specific revisions separated by commas, or a range of revisions separated by a dash, or any combination of these.

Se precisas de especificar uma revisão cavilha para a integração, adiciona a revisão cavilha no fim das revisões, e.g. 5-7,10@3. No exemplo acima, as revisões 5,6,7 e 10 seriam integradas, sendo a 3 a revisão cavilha.

The easiest way to select the range of revisions you need is to click on Show Log, as this will list recent changes with their log comments. If you want to merge the changes from a single revision, just select that revision. If you want to merge changes from several revisions, then select that range (using the usual Shift-modifier). Click on OK and the list of revision numbers to merge will be filled in for you.

If you want to merge changes back out of your working copy, to revert a change which has already been committed, select the revisions to revert and make sure the Reverse merge box is checked.

If you have already merged some changes from this branch, hopefully you will have made a note of the last revision merged in the log message when you committed the change. In that case, you can use Show Log for the Working Copy to trace that log message. Remembering that we are thinking of revisions as changesets, you should Use the revision after the end point of the last merge as the start point for this merge. For example, if you have merged revisions 37 to 39 last time, then the start point for this merge should be revision 40.

If you are using the merge tracking features of Subversion, you do not need to remember which revisions have already been merged - Subversion will record that for you. If you leave the revision range blank, all revisions which have not yet been merged will be included. Read “Histórico de combinações” to find out more.

Quando o seguimento de integração é usado, a caixa de diálogo de registo irá mostrar as revisões previamente integradas e as revisões antecedentes ao ponto do antecessor comum, i.e. antes do ramo ser copiado, a cinzento. A caixa de verificação Ocultar revisões não.integráveis permite-te filtrar completamente essas revisões, para que vejas apenas as revisões que podem ser integradas.

If other people may be committing changes then be careful about using the HEAD revision. It may not refer to the revision you think it does if someone else made a commit after your last update.

If you leave the range of revisions empty or have the radio button all revisions checked, then Subversion merges all not-yet merged revisions. This is known as a reintegrate or automatic merge.

Existem algumas condições que se aplicam a uma integração de reintegração. Primeiramente, o servidor deverá suportar o rastreamento de integração. A cópia de trabalho deverá ser de nível infinito (sem checkouts dispersos), e não deverá ter nenhumas alterações, itens trocados ou itens que foram actualizadas para revisões diferentes da HEAD. Todas as alterações para o trunk feitas durante o desenvolvimento do ramo, deverão ter sido já integradas transversalmente para o ramo (ou marcadas como tendo sido feitas). O intervalo de revisões a integrar será então calculado automaticamente.

Click Next and go to “Opções de Combinação”.

Figura 4.53. O Assistente de Combinação - Árvore de Combinação

If you are using this method to merge a feature branch back to trunk, you need to start the merge wizard from within a working copy of trunk.

In the From: field enter the full folder URL of the trunk. This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes. You may also click ... to browse the repository.

In the To: field enter the full folder URL of the feature branch.

In both the From Revision field and the To Revision field, enter the last revision number at which the two trees were synchronized. If you are sure no-one else is making commits you can use the HEAD revision in both cases. If there is a chance that someone else may have made a commit since that synchronization, use the specific revision number to avoid losing more recent commits.

Você também pode utilizar o Visualizar Histórico para selecionar a revisão.

This page of the wizard lets you specify advanced options, before starting the merge process. Most of the time you can just use the default settings.

Tu podes especificar o nível a usar na integração, i.e. até que ponto deverá a integração penetrar na tua cópia de trabalho. Os termos do nível usados estão descritos em “Profundidade da Obtenção”. O nível por defeito é a Cópia de trabalho, e é quase sempre o que precisas.

Most of the time you want merge to take account of the file's history, so that changes relative to a common ancestor are merged. Sometimes you may need to merge files which are perhaps related, but not in your repository. For example you may have imported versions 1 and 2 of a third party library into two separate directories. Although they are logically related, Subversion has no knowledge of this because it only sees the tarballs you imported. If you attempt to merge the difference between these two trees you would see a complete removal followed by a complete add. To make Subversion use only path-based differences rather than history-based differences, check the Ignore ancestry box. Read more about this topic in the Subversion book, Noticing or Ignoring Ancestry.

You can specify the way that line ending and whitespace changes are handled. These options are described in “Opções de Quebra de Linha e Espaços em Branco”. The default behaviour is to treat all whitespace and line-end differences as real changes to be merged.

The checkbox marked Force the merge is used to avoid a tree conflict where an incoming delete affects a file that is either modified locally or not versioned at all. If the file is deleted then there is no way to recover it, which is why that option is not checked by default.

If you are using merge tracking and you want to mark a revision as having been merged, without actually doing the merge here, check the Only record the merge checkbox. There are two possible reasons you might want to do this. It may be that the merge is too complicated for the merge algorithms, so you code the changes by hand, then mark the change as merged so that the merge tracking algorithm is aware of it. Or you might want to prevent a particular revision from being merged. Marking it as already merged will prevent the merge occurring with merge-tracking-aware clients.

Now everything is set up, all you have to do is click on the Merge button. If you want to preview the results Test Merge simulates the merge operation, but does not modify the working copy at all. It shows you a list of the files that will be changed by a real merge, and notes files where conflicts may occur. Because merge tracking makes the merge process a lot more complicated, there is no guaranteed way to find out in advance whether the merge will complete without conflicts, so files marked as conflicted in a test merge may in fact merge without any problem.

The merge progress dialog shows each stage of the merge, with the revision ranges involved. This may indicate one more revision than you were expecting. For example if you asked to merge revision 123 the progress dialog will report “ Merging revisions 122 through 123 ”. To understand this you need to remember that Merge is closely related to Diff. The merge process works by generating a list of differences between two points in the repository, and applying those differences to your working copy. The progress dialog is simply showing the start and end points for the diff.

The merge is now complete. It's a good idea to have a look at the merge and see if it's as expected. Merging is usually quite complicated. Conflicts often arise if the branch has drifted far from the trunk.

For Subversion clients and servers prior to 1.5, no merge information is stored and merged revisions have to be tracked manually. When you have tested the changes and come to commit this revision, your commit log message should always include the revision numbers which have been ported in the merge. If you want to apply another merge at a later time you will need to know what you have already merged, as you do not want to port a change more than once. For more information about this, refer to Best Practices for Merging in the Subversion book.

If your server and all clients are running Subversion 1.5 or higher, the merge tracking facility will record the revisions merged and avoid a revision being merged more than once. This makes your life much simpler as you can simply merge the entire revision range each time and know that only new revisions will actually be merged.

Branch management is important. If you want to keep this branch up to date with the trunk, you should be sure to merge often so that the branch and trunk do not drift too far apart. Of course, you should still avoid repeated merging of changes, as explained above.

Subversion 1.5 introduced facilities for merge tracking. When you merge changes from one tree into another, the revision numbers merged are stored and this information can be used for several different purposes.

Merge tracking information is stored in the svn:mergeinfo property by the client when it performs a merge. When the merge is committed the server stores that information in a database, and when you request merge, log or blame information, the server can respond appropriately. For the system to work properly you must ensure that the server, the repository and all clients are upgraded. Earlier clients will not store the svn:mergeinfo property and earlier servers will not provide the information requested by new clients.

Mais informações sobre o controlo de integração do Subversion em; Merge tracking documentation.

Merging does not always go smoothly. Sometimes there is a conflict. TortoiseSVN helps you through this process by showing the merge conflict dialog.

Figura 4.54. The Merge Conflict Dialog

It is likely that some of the changes will have merged smoothly, while other local changes conflict with changes already committed to the repository. All changes which can be merged are merged. The Merge Conflict dialog gives you different ways of handling the lines which are in conflict.

For normal conflicts that happen due to changes in the file content or its properties, the dialog shows buttons which allow you to chose which of the conflicting parts to keep or reject.

If there's a tree conflict, please first see “Conflitos de Estrutura” about the various types of tree conflicts and how and why they can happen.

To resolve tree conflicts after a merge, a dialog is shown with various options on how to resolve the conflict:

Figura 4.55. The Merge Tree Conflict Dialog

Since there are various possible tree conflict situations, the dialog will show buttons to resolve those depending on the specific conflict. The button texts and labels explain what the option to resolve the conflict does. If you're not sure, either cancel the dialog or use the Postpone button to resolve the conflict later.

When you develop a new feature on a separate branch it is a good idea to work out a policy for re-integration when the feature is complete. If other work is going on in trunk at the same time you may find that the differences become significant over time, and merging back becomes a nightmare.

If the feature is relatively simple and development will not take long then you can adopt a simple approach, which is to keep the branch entirely separate until the feature is complete, then merge the branch changes back into trunk. In the merge wizard this would be a simple Merge a range of revisions, with the revision range being the revision span of the branch.

If the feature is going to take longer and you need to account for changes in trunk, then you need to keep the branch synchronised. This simply means that periodically you merge trunk changes into the branch, so that the branch contains all the trunk changes plus the new feature. The synchronisation process uses Merge a range of revisions. When the feature is complete then you can merge it back to trunk using either Reintegrate a branch or Merge two different trees.

Another (fast) way to merge all changes from trunk to the feature branch is to use the TortoiseSVN → Merge all... from the extended context menu (hold down the Shift key while you right click on the file).

Figura 4.56. The Merge-All Dialog

This dialog is very easy. All you have to do is set the options for the merge, as described in “Opções de Combinação”. The rest is done by TortoiseSVN automatically using merge tracking.

Por padrão, nada é bloqueado e qualquer um que tenha acesso para submissão pode alterar qualquer arquivo a qualquer momento. Outros atualizarão suas cópias de trabalho periodicamente e as mudanças no repositório serão combinadas com as alterações locais.

If you Get a Lock on a file, then only you can commit that file. Commits by all other users will be blocked until you release the lock. A locked file cannot be modified in any way in the repository, so it cannot be deleted or renamed either, except by the lock owner.

However, other users will not necessarily know that you have taken out a lock. Unless they check the lock status regularly, the first they will know about it is when their commit fails, which in most cases is not very useful. To make it easier to manage locks, there is a new Subversion property svn:needs-lock. When this property is set (to any value) on a file, whenever the file is checked out or updated, the local copy is made read-only unless that working copy holds a lock for the file. This acts as a warning that you should not edit that file unless you have first acquired a lock. Files which are versioned and read-only are marked with a special overlay in TortoiseSVN to indicate that you need to acquire a lock before editing.

Locks are recorded by working copy location as well as by owner. If you have several working copies (at home, at work) then you can only hold a lock in one of those working copies.

If one of your co-workers acquires a lock and then goes on holiday without releasing it, what do you do? Subversion provides a means to force locks. Releasing a lock held by someone else is referred to as Breaking the lock, and forcibly acquiring a lock which someone else already holds is referred to as Stealing the lock. Naturally these are not things you should do lightly if you want to remain friends with your co-workers.

Locks are recorded in the repository, and a lock token is created in your local working copy. If there is a discrepancy, for example if someone else has broken the lock, the local lock token becomes invalid. The repository is always the definitive reference.

Select the file(s) in your working copy for which you want to acquire a lock, then select the command TortoiseSVN → Get Lock....

Figura 4.57. A Janela de Bloqueio

A dialog appears, allowing you to enter a comment, so others can see why you have locked the file. The comment is optional and currently only used with Svnserve based repositories. If (and only if) you need to steal the lock from someone else, check the Steal lock box, then click on OK.

You can set the project property tsvn:logtemplatelock to provide a message template for users to fill in as the lock message. Refer to “Configurações do Projeto” for instructions on how to set properties.

If you select a folder and then use TortoiseSVN → Get Lock... the lock dialog will open with every file in every sub-folder selected for locking. If you really want to lock an entire hierarchy, that is the way to do it, but you could become very unpopular with your co-workers if you lock them out of the whole project. Use with care ...

To make sure you don't forget to release a lock you don't need any more, locked files are shown in the commit dialog and selected by default. If you continue with the commit, locks you hold on the selected files are removed, even if the files haven't been modified. If you don't want to release a lock on certain files, you can uncheck them (if they're not modified). If you want to keep a lock on a file you've modified, you have to enable the Keep locks checkbox before you commit your changes.

To release a lock manually, select the file(s) in your working copy for which you want to release the lock, then select the command TortoiseSVN → Release Lock There is nothing further to enter so TortoiseSVN will contact the repository and release the locks. You can also use this command on a folder to release all locks recursively.

Figura 4.58. A Janela de Verificação de Modificações

To see what locks you and others hold, you can use TortoiseSVN → Check for Modifications.... Locally held lock tokens show up immediately. To check for locks held by others (and to see if any of your locks are broken or stolen) you need to click on Check Repository.

A partir deste menu de contexto você pode também obter ou liberar bloqueios, assim como quebrar e roubar os bloqueios mantidos por outros.

As mentioned above, the most effective way to use locking is to set the svn:needs-lock property on files. Refer to “Configurações do Projeto” for instructions on how to set properties. Files with this property set will always be checked out and updated with the read-only flag set unless your working copy holds a lock.

As a reminder, TortoiseSVN uses a special overlay to indicate this.

If you operate a policy where every file has to be locked then you may find it easier to use Subversion's auto-props feature to set the property automatically every time you add new files. Read “Definição automática de propriedade” for further information.

Quando você criar um novo repositório com o Subversion 1.2 ou superior, quatro modelos de gancho são criados no diretório hooks no repositório. Eles são chamados antes e depois de efetuar um bloqueio, e antes e depois de liberar um bloqueio.

It is a good idea to install a post-lock and post-unlock hook script on the server which sends out an email indicating the file which has been locked. With such a script in place, all your users can be notified if someone locks/unlocks a file. You can find an example hook script hooks/post-lock.tmpl in your repository folder.

Você também pode usar ganchos para proibir a quebra ou o roubo de travas, ou talvez limitá-lo a um administrador nomeado. Ou talvez você queira enviar um e-mail para o proprietário quando um de seus bloqueios é quebrado ou roubado.

Leia “Rotinas de eventos no servidor” para saber mais.

First you need to make and test your changes. Then instead of using TortoiseSVN → Commit... on the parent folder, you select TortoiseSVN → Create Patch...

Figura 4.59. A Janela de Criação de Correções

you can now select the files you want included in the patch, just as you would with a full commit. This will produce a single file containing a summary of all the changes you have made to the selected files since the last update from the repository.

As colunas nesta janela podem ser personalizadas da mesma forma como as colunas da janela Verificar alterações. Leia “Estado Local e Remoto” para mais detalhes.

Ao clicar no botão de Opções, podes especificar como o caminho é criado. Por exemplo, podes especificar que as mudanças no final da linha ou espaços em branco não são incluídas no arquivo do caminho final.

You can produce separate patches containing changes to different sets of files. Of course, if you create a patch file, make some more changes to the same files and then create another patch, the second patch file will include both sets of changes.

Just save the file using a filename of your choice. Patch files can have any extension you like, but by convention they should use the .patch or .diff extension. You are now ready to submit your patch file.

You can also save the patch to the clipboard instead of to a file. You might want to do this so that you can paste it into an email for review by others. Or if you have two working copies on one machine and you want to transfer changes from one to the other, a patch on the clipboard is a convenient way of doing this.

Se preferires podes criar um ficheiro correcção a partir das caixas de diálogo Submeter ou Verificar alterações. Selecciona apenas os ficheiros e usa o item do menu de contexto para criar a correcção a partir desses ficheiros. Se quiseres ver a caixa de diálogo Opções terás de manter premida a tecla shift quando clicares à direita.

Patch files are applied to your working copy. This should be done from the same folder level as was used to create the patch. If you are not sure what this is, just look at the first line of the patch file. For example, if the first file being worked on was doc/source/english/chapter1.xml and the first line in the patch file is Index: english/chapter1.xml then you need to apply the patch to the doc/source/ folder. However, provided you are in the correct working copy, if you pick the wrong folder level, TortoiseSVN will notice and suggest the correct level.

In order to apply a patch file to your working copy, you need to have at least read access to the repository. The reason for this is that the merge program must reference the changes back to the revision against which they were made by the remote developer.

From the context menu for that folder, click on TortoiseSVN → Apply Patch... This will bring up a file open dialog allowing you to select the patch file to apply. By default only .patch or .diff files are shown, but you can opt for “All files”. If you previously saved a patch to the clipboard, you can use Open from clipboard... in the file open dialog. Note that this option only appears if you saved the patch to the clipboard using TortoiseSVN → Create Patch.... Copying a patch to the clipboard from another app will not make the button appear.

Alternatively, if the patch file has a .patch or .diff extension, you can right click on it directly and select TortoiseSVN → Apply Patch.... In this case you will be prompted to enter a working copy location.

These two methods just offer different ways of doing the same thing. With the first method you select the WC and browse to the patch file. With the second you select the patch file and browse to the WC.

Once you have selected the patch file and working copy location, TortoiseMerge runs to merge the changes from the patch file with your working copy. A small window lists the files which have been changed. Double click on each one in turn, review the changes and save the merged files.

The remote developer's patch has now been applied to your working copy, so you need to commit to allow everyone else to access the changes from the repository.

Figura 4.60. A Janela de Anotação / Autoria

If you're not interested in changes from earlier revisions you can set the revision from which the blame should start. Set this to 1, if you want the blame for every revision.

By default the blame file is viewed using TortoiseBlame, which highlights the different revisions to make it easier to read. If you wish to print or edit the blame file, select Use Text viewer to view blames.

You can specify the way that line ending and whitespace changes are handled. These options are described in “Opções de Quebra de Linha e Espaços em Branco”. The default behaviour is to treat all whitespace and line-end differences as real changes, but if you want to ignore an indentation change and find the original author, you can choose an appropriate option here.

Ter em atenção que se uma etiqueta é usada como origem para uma cópia, talvez um novo ramo baseado numa etiqueta, então essa etiqueta será mostrada como um nó separado em vez de dobrada.

Once you press OK TortoiseSVN starts retrieving the data to create the blame file. Once the blame process has finished the result is written into a temporary file and you can view the results.

Figura 4.61. TortoiseBlame

TortoiseBlame, which is included with TortoiseSVN, makes the blame file easier to read. When you hover the mouse over a line in the blame info column, all lines with the same revision are shown with a darker background. Lines from other revisions which were changed by the same author are shown with a light background. The colouring may not work as clearly if you have your display set to 256 colour mode.

If you left click on a line, all lines with the same revision are highlighted, and lines from other revisions by the same author are highlighted in a lighter colour. This highlighting is sticky, allowing you to move the mouse without losing the highlights. Click on that revision again to turn off highlighting.

The revision comments (log message) are shown in a hint box whenever the mouse hovers over the blame info column. If you want to copy the log message for that revision, use the context menu which appears when you right click on the blame info column.

You can search within the Blame report using Edit → Find.... This allows you to search for revision numbers, authors and the content of the file itself. Log messages are not included in the search - you should use the Log Dialog to search those.

You can also jump to a specific line number using Edit → Go To Line....

When the mouse is over the blame info columns, a context menu is available which helps with comparing revisions and examining history, using the revision number of the line under the mouse as a reference. Context menu → Blame previous revision generates a blame report for the same file, but using the previous revision as the upper limit. This gives you the blame report for the state of the file just before the line you are looking at was last changed. Context menu → Show changes starts your diff viewer, showing you what changed in the referenced revision. Context menu → Show log displays the revision log dialog starting with the referenced revision.

If you need a better visual indicator of where the oldest and newest changes are, select View → Color age of lines. This will use a colour gradient to show newer lines in red and older lines in blue. The default colouring is quite light, but you can change it using the TortoiseBlame settings.

Se estás a usar o rastreamento de integração e pediste info. de integração ao iniciar a responsabilização, então as linhas integradas são mostradas de um modo ligeiramente diferente. Onde foi alterada uma linha como resultado de uma integração de outro ramo, o TortoiseBlame irá mostrar a revisão e o autor da última alteração no ficheiro original em vez da revisão onde foi efectuada a integração. Essas linhas são identificadas ao mostrar a revisão e o autor em itálico. A revisão onde foi efectuada a integração é mostrada em separado na tooltip quando passas o rato sobre as colunas de info. de responsabilidade. Se não pretenderes que as linhas integradas sejam mostradas desta maneira, desselecciona a caixa Incluir info de integração ao iniciar a responsabilização.

Se quiseres ver os caminhos envolvidos na mesclagem, selecciona Ver → Mesclar caminhos. Isso irá mostrar o caminho onde a linha foi modificada pela última vez, excluindo as variações resultantes de uma fusão.

A revisão mostrada na informação de responsabilidade representa a última revisão onde o conteúdo dessa linha foi alterado. Se o ficherio foi criado ao copiar outro ficheiro, então até alterares a linha, a sua revisão de responsabilidade irá mostrar a última alteração no ficheiro fonte original, e não a revisão onde a cópia foi efectuada. Isto também se aplica aos caminhos mostrados com a informação de integração. O caminho mostra a localização do repositório onde a última alteração foi efectuada a essa linha.

The settings for TortoiseBlame can be accessed using TortoiseSVN → Settings... on the TortoiseBlame tab. Refer to “Configurações TortoiseBlame”.

Limpa o estado da cópia de trabalho

A janela de auditoria de revisão inclui diversas opções que lhe permitem fazer isto.

Cada nó do grafo de revisões representa uma revisão no repositório onde algo foi alterado, na árvore que estás a observar. Diferentes tipos de nós podem ser distinguidos através da forma e cor. As formas são fixas, mas as cores podem ser alteradas usando TortoiseSVN → preferências

De notar que por defeito, o grafo só mostra os pontos onde itens foram adicionados, copiados ou removidos. Mostrando cada revisão do projecto irá gerar um grafo muito extenso para casos não triviais. Se queres realmente ver todas as revisões onde foram feitas alterações, existe uma opção para o fazer no menu Ver e na barra de ferramentas.

A vista por defeito (sem agrupamento) coloca os nós de modo que a sua posição vertical fique na ordem estrita de revisões, para que tenhas uma dica visual da ordem em que as coisas foram feitas. Quando estão na mesma coluna dois nós, a ordem é muito óbvia. Quando estão em colunas adjacentes dois nós, o deslocamento é muito menor porque não há necessidade de evitar que os nós se sobreponham, e como resultado a ordem é um pouco menos óbvia. Tais optimizações são necessárias de modo a manter a complexidade dos grafos numa dimensão aceitável. Ter em atenção que esta ordenação usa o canto do nó no lado mais antigo como referência, i.e. o canto inferior do nó, quando o grafo é mostrado com os nós mais antigos no fundo. O canto de referência é significativo porque todas as formas de nós não são da mesma altura.

Because a revision graph is often quite complex, there are a number of features which can be used to tailor the view the way you want it. These are available in the View menu and from the toolbar.

To make it easier to navigate a large graph, use the overview window. This shows the entire graph in a small window, with the currently displayed portion highlighted. You can drag the highlighted area to change the displayed region.

The revision date, author and comments are shown in a hint box whenever the mouse hovers over a revision box.

If you select two revisions (Use Ctrl-left click), you can use the context menu to show the differences between these revisions. You can choose to show differences as at the branch creation points, but usually you will want to show the differences at the branch end points, i.e. at the HEAD revision.

You can view the differences as a Unified-Diff file, which shows all differences in a single file with minimal context. If you opt to Context Menu → Compare Revisions you will be presented with a list of changed files. Double click on a file name to fetch both revisions of the file and compare them using the visual difference tool.

If you right click on a revision you can use Context Menu → Show Log to view the history.

You can also merge changes in the selected revision(s) into a different working copy. A folder selection dialog allows you to choose the working copy to merge into, but after that there is no confirmation dialog, nor any opportunity to try a test merge. It is a good idea to merge into an unmodified working copy so that you can revert the changes if it doesn't work out! This is a useful feature if you want to merge selected revisions from one branch to another.

If you want to check the server again for newer information, you can simply refresh the view using F5. If you are using the log cache (enabled by default), this will check the repository for newer commits and fetch only the new ones. If the log cache was in offline mode, this will also attempt to go back online.

If you are using the log cache and you think the message content or author may have changed, you should use the log dialog to refresh the messages you need. Since the revision graph works from the repository root, we would have to invalidate the entire log cache, and refilling it could take a very long time.

A large tree can be difficult to navigate and sometimes you will want to hide parts of it, or break it down into a forest of smaller trees. If you hover the mouse over the point where a node link enters or leaves the node you will see one or more popup buttons which allow you to do this.

Click on the minus button to collapse the attached sub-tree.

Click on the plus button to expand a collapsed tree. When a tree has been collapsed, this button remains visible to indicate the hidden sub-tree.

Click on the cross button to split the attached sub-tree and show it as a separate tree on the graph.

Click on the circle button to reattach a split tree. When a tree has been split away, this button remains visible to indicate that there is a separate sub-tree.

Click on the graph background for the main context menu, which offers options to Expand all and Join all. If no branch has been collapsed or split, the context menu will not be shown.

Por vezes terás uma cópia de trabalho que pretendes converter de volta para uma pasta normal, ou seja, sem a pasta .svn. Tudo o que precisarás de fazer é apagar a pasta .svn da raiz da tua cópia de trabalho.

Alternatively you can export the folder to itself. In Windows Explorer right drag the working copy root folder from the file pane onto itself in the folder pane. TortoiseSVN detects this special case and asks if you want to make the working copy unversioned. If you answer yes the control directory will be removed and you will have a plain, unversioned directory tree.

You can integrate a bug tracking tool of your choice in TortoiseSVN. To do this, you have to define some properties, which start with bugtraq:. They must be set on Folders: (“Configurações do Projeto”)

Figura 4.66. Caixa de diálogo de Propriedades do Bugtraq

Quando editas qualquer uma das propriedades do bugtraq, um editor de propriedade especial será usado para tornar mais fácil definir os valores adequados.

There are two ways to integrate TortoiseSVN with issue trackers. One is based on simple strings, the other is based on regular expressions. The properties used by both approaches are:

If both the bugtraq:message and bugtraq:logregex properties are set, logregex takes precedence.

Some tsvn: properties require a true/false value. TortoiseSVN also understands yes as a synonym for true and no as a synonym for false.

When you add new sub-folders to a working copy using TortoiseSVN, any project properties present in the parent folder will automatically be added to the new child folder too.

This issue tracker integration is not restricted to TortoiseSVN; it can be used with any Subversion client. For more information, read the full Issue Tracker Integration Specification in the TortoiseSVN source repository. (“Licença” explains how to access the repository.)

The previous section deals with adding issue information to the log messages. But what if you need to get information from the issue tracker? The commit dialog has a COM interface which allows integration an external program that can talk to your tracker. Typically you might want to query the tracker to get a list of open issues assigned to you, so that you can pick the issues that are being addressed in this commit.

Any such interface is of course highly specific to your issue tracker system, so we cannot provide this part, and describing how to create such a program is beyond the scope of this manual. The interface definition and sample plugins in C# and C++/ATL can be obtained from the contrib folder in the TortoiseSVN repository. (“Licença” explains how to access the repository.) A summary of the API is also given in Capítulo 7, IBugtraqProvider interface. Another (working) example plugin in C# is Gurtle which implements the required COM interface to interact with the Google Code issue tracker.

For illustration purposes, let's suppose that your system administrator has provided you with an issue tracker plugin which you have installed, and that you have set up some of your working copies to use the plugin in TortoiseSVN's settings dialog. When you open the commit dialog from a working copy to which the plugin has been assigned, you will see a new button at the top of the dialog.

Figura 4.67. Janela de exemplo de uma consulta de um rastreador de reportes

In this example you can select one or more open issues. The plugin can then generate specially formatted text which it adds to your log message.

Figura 4.68. Janela de Configurações, Opção Geral

This dialog allows you to specify your preferred language, and the Subversion-specific settings.