Tortoise SVN - Parte 4

Este documento descreve o uso diário do cliente TortoiseSVN. Este capítulo não é uma introdução aos sistemas de controle de versão, e não é uma introdução ao Subversion (SVN). Este capítulo é como um documento auxiliar para olhar quando você sabe mais ou menos o que quer fazer, mas não está absolutamente certo de como fazer.
Se você precisa aprender sobre o controle de versão usando Subversion, então nós recomendamos que você leia o fantástico livro: Controle de Versão com Subversion.
Este documento é também um trabalho em progresso, assim como TortoiseSVN e Subversion também são. Se você encontrar qualquer erro, por favor reporte para a lista de discussão para que possamos atualizar a documentação. Algumas imagens do Guia do Uso Diário (GUD) pode não refletir a última versão do aplicativo. Por favor, perdoe-nos. Nós trabalhamos no TortoiseSVN no nosso tempo livre.
A fim de obter o máximo do Guia de Uso Diário:

• Você já deverá ter instalado o TortoiseSVN.
• Você deverá estar familiarizado com um sistema de controle de versões.
• Você deverá ter conhecimentos básicos do Subversion.
• Você deve ter configurado um servidor e/ou ter acesso a um repositório Subversion.

General Features

Esta seção descreve algumas das características do TortoiseSVN que se aplicam a praticamente tudo no manual. Note-se que muitos desses recursos só vai aparecer em uma cópia de trabalho do Subversion.

Sobreposição dos Ícones

 

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.

Menus do Contexto

 

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.

Dica

Alguns comandos que são raramente usados estão disponíveis apenas em no menu de contexto extendido. Para ver o menu de contexto extendido, segure a tecla Shift quando você clicar com o botão direito.

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

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.
Se você utiliza Windows 2000 descobrirá que os menus de contexto são mostrados com texto liso, sem os ícones de menu por cima. Estamos conscientes que isto foi trabalhado em versões anteriores, mas a Microsoft mudou a forma como os manipuladores de ícones funcionam para o vista, exigindo que nós usássemos um método diferente de mostrá-los, que infelizmente não funciona em Windows 2000.

Arrastar e Soltar

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.

Atalhos Comuns

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.

F1

Ajuda, claro.

F5

Atualiza a visualização atual. Este talvez seja o mais útil comando de uma única tecla. Por exemplo... No Explorer ele irá atualizar os ícones sobrepostos na sua cópia de trabalho. Na janela de Commit irá reexplorar a Cópia de Trabalho para ver o que precisa ser enviado. Na janela Revision Log irá verificar o repositório novamente a procura de novas modificações recentes.

Ctrl-A

Seleciona tudo. Pode ser usado se você tiver uma mensagem de erro e precisar copiar e colar em um email. Use Ctrl-A para selecionar a mensagem e então...

Ctrl-C

... Copia o texto selecionado.

Autenticação

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

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:

• svn.simple contém as credenciais básicas de autenticação (nome do usuário/senha). Observe que as senhas são armazenadas e encriptadas com o uso do WinCrypt API, não são armazenadas no formato "texto".
• svn.ssl.server contém os certificados do servidor para SSL.
• svn.username contém credenciais para autenticações que necessitem apenas do nome de usuário (não é necessário senha).

Se você quiser limpar o cache de autenticação para todos os servidores, você poderá fazê-lo através da página Saved Data da página de configurões do TortoiseSVN. O botão limpa todos os dados de autenticação em cache dos diretórios auth do Subversion, assim como qualquer dados de autenticação armazenados no registro por versões anteriores do TortoiseSVN. Veja “Saved Data Settings”.
Se você quer apagar a autenticação de um só domínio você terá que procurar dentro dos diretórios, e encontrar o arquivo que contêm a informação que você quer e então limpar e apagar o arquivo.
Algumas pessoas gostam de limpar os dados de autenticação quando eles encerram a sessão do Windows, ou quando desligam o computador. A maneira de fazer isto é usar um script ao desligar para apagar o diretório %APPDATA%\Subversion\auth, ex.

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

Você pode encontrar uma descrição de como instalar tal script em 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”.

Maximizando Janelas

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.

Importando Dados Para Um Repositório

Importar

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.
This section describes the Subversion import command, which was designed for importing a directory hierarchy into the repository in one shot. Although it does the job, it has several shortcomings:

• Não há qualquer maneira de selecionar os arquivos e pastas que deverão ser incluídos, em compensação poderá utilizar as configurações globais para ignorar alguns arquivos e pastas.
• A pasta importada não se torna uma cópia de trabalho. Você tem que fazer um checkout para copiar os arquivos desde o servidor.
• É fácil importar para uma pasta equivocada no repositório.

For these reasons we recommend that you do not use the import command at all but rather follow the two-step method described in “Importando na Pasta”, unless you are performing the simple step of creating an initial /trunk /tags /branches structure in your repository. Since you are here, this is how the basic import works ...
Antes de importar seu projeto para um repositório, você deveria:

1. Remova todos os arquivos que não são necessários para construir o projeto (arquivos temporários, arquivos que são gerados por um compilador como por exemplo *. obj, binários compilados, ...)
2. Organize os arquivos em pastas e sub-pastas. Embora posteriormente seja possível renomear/mover arquivos, é altamente recomendado que obtenha a estrutura correta do seu projeto antes de realizar a importação!

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 ...
Nesta janela de diálogo, você deve digitar a URL do local do repositório para onde você deseja importar o seu projeto. É muito importante que a pasta local que está importando não apareça no repositório, mas apenas o seu conteúdo. Por exemplo, se você tem uma estrutura:

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

e você está importando C:\Projects\Widget para http://mydomain.com/svn/trunk você se surpreenderá ao descobrir que seu subdiretórios irão diretamente para trunk, ao invés de irem para o subdiretório Widget. Você deverá especificar o subdiretório como parte do URL, http://mydomain.com/svn/trunk/Widget-X. Note que o comando de importação irá criar automaticamente subdiretórios dentro do repositório se eles não existirem.
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".

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:

1. Use the repository browser to create a new project folder directly in the repository. If you are using one of the standard layouts you will probably want to create this as a sub-folder of trunk rather than in the repository root. The repository browser shows the repository structure just like Windows explorer, so you can see how things are organised.
2. Checkout the new folder over the top of the folder you want to import. You will get a warning that the local folder is not empty. Ignore the warning. Now you have a versioned top level folder with unversioned content.
3. Use TortoiseSVN → Adicionar... na pasta sob controle de versão para adicionar algum ou todo conteúdo. Você pode adicionar e remover arquivos, defina as configurações em svn:ignore para as pastas e faça outras alterações que você necessita.
4. Ao submeter a pasta de nível superior, você terá uma nova "árvore" sob controle de versão e uma cópia local de trabalho, criada a partir de sua pasta existente.

Arquivos Especiais

À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
Por exemplo, veja que script TortoiseSVN chama um arquivo chamado TortoiseVars.bat que não existe no repositório. Somente existe o arquivo TortoiseVars.tmpl. TortoiseVars.tmpl é o arquivo modelo que cada colaborador deve criar uma cópia e renomear a cópia para TortoiseVars.bat. Nesse arquivo, adicionamos comentários para que os usuários vejam as linhas que eles devem editar e mudar de acordo com sua instalação local.
Portanto, para não aborrecer usuários, também adicionamos o arquivo TortoiseVars.bat para a lista de "ignorados" da pasta que o contém, ou seja, configuramos svn:ignore para incluir esse arquivo. Dessa forma, ele não aparecerá como "não versionado" em cada submissão.

Para obter uma cópia de trabalho você precisa realizar um obter do repositório.
Selecione um diretório no windows explorer onde você quer deixar sua cópia de trabalho. Clique direito para abrir o menu de contexto e então selecione o comando TortoiseSVN → Obter..., o qual abrir a seguinte janela:

Se você digitar o nome de um diretório que não existe ainda, então um diretório com este nome será criado.

Profundidade da Obtenção

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.

Totalmente recursiva

Obter estrutura completa, incluindo todos os níveis de sub diretórios.

Filhos imediatos, incluindo pastas

Obter o diretório especificado, incluindo todos os arquivos e sub diretórios, mas não carregar os sub diretórios.

Somente os arquivos filhos

Ober o diretório especificado, incluindo todos os arquivos mas não obter qualquer sub diretório.

Somente este item

Obter apenas o diretório. Não carregar com arquivos ou sub diretórios.

Cópia de trabalho

Retêm a profundidade especificada na cópia de trabalho. Esta opção não é usada na janela de obtenção, mas é o padrão em todas as outras janelas que tem a configuração de profundidade.

Excluir

Usado para reduzir a profundidade da cópia de trabalho depois de uma pasta já ter sido carregada. Esta opção está somente disponível na janela Atualizar para a revisão.

Para selecionar facilmente apenas os itens que você deseja para o check-out e forçar a cópia de trabalho resultante para manter somente os itens, clique nos itens escolher ... botão. Isso abre uma nova janela onde você pode verificar todos os itens que você deseja em sua cópia de trabalho e desmarque todos os itens que você não quer. A cópia de trabalho resultante é então conhecido como uma verificação escassa. Uma atualização de um exemplar desse tipo de trabalho não vai buscar os arquivos perdidos e pastas, mas apenas atualizar o que você já tem em sua cópia de trabalho.

Se você verificar uma cópia de trabalho escassa (ou seja, ao escolher algo que não seja totalmente recursiva para a profundidade checkout), você pode facilmente adicionar ou remover sub-pastas mais tarde usando um dos seguintes métodos.

Atualização Sparse usando Atualizar para revisão

Botão direito do mouse sobre a pasta check-out, em seguida, usar TortoiseSVN → Atualizar para revisão e selecione Escolher itens .... Isso abre a mesma janela que estava disponível no check-out original e permite que você selecione ou desmarque os itens a serem incluídos no checkout. Este método é muito flexível, mas pode ser lento como cada item na pasta é atualizado individualmente.Atualização Sparse usando Repo Navegador
Botão direito do mouse sobre a pasta check-out, em seguida, usar TortoiseSVN → Repo -Browser para abrir o navegador de repositório . Encontre o sub- pasta que você gostaria de adicionar à sua cópia de trabalho , então use Context Menu → Atualizar item para revisão ....Sparse atualização usando a opção Verificar Modificações
Na caixa de diálogo verificar modificações, primeiro turno clique no botão Verificar repositório . A caixa de diálogo irá mostrar todos os arquivos e pastas que estão no repositório , mas que você não tenha feito check-out adicionado como remotamente. Botão direito do mouse sobre a pasta (s ) que você gostaria de adicionar à sua cópia de trabalho , então use o menu de contexto → Update.

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:

1. Obter o diretório pai com profundidade “Somente este item”. Você agora tem um diretório do nível mais alto.
2. Selectionar um novo diretório e usar TortoiseSVN → Navegador de repositório para mostrar o conteúdo do repositório.
3. Clique direito sobre Projeto03 e Menu de Contexto → Atualizar item para a revisão.... Deixe as configurações padrões e clique em OK. Você agora terá um diretório carregado.
   Repetir o mesmo processo para Projeto25.
4. Navegu para Projeto76 e faça a mesma coisa. Agora note que o diretório Projeto76 não tem nada exceto o SubProj, o qual ele mesmo está carregado. Subversion criou os diretórios intermediários para você sem carregá-los.

Mudando a profundidade da cópia de trabalho

Uma vez que você obteve uma cópia de trabalho para uma profundidade particular você pode mudar a profundidade posteriormente para obter mais ou menos arquivos usando Menu de Contexto → Atualizar item para a revisão.... Nesta janela, tenha certeza que a opção Deixar a profundidade colada marcada.

Usando um servidor antigo

Servidores pré-1.5 não entendem a requisição de profundidade de uma cópia de trabalho, então eles nem sempre responderão esse pedido de forma eficiente. O comando continuará funcionando, mas servidores mais antigos poderão enviar todos os dados, deixando o cliente para filtrar o que não é requerido, o que significa mais tráfego de rede. Se possível você deverá atualizar seu servidor para uma versão mais nova que 1.5.

Se o projeto contém referências para projetos externos os quais você não quer obter no mesmo momento, use a caixa de seleção Omitir externos.

Importante

Se Omitir externos está mrcado, ou se você quer incrementar a profundidade, você precisa executar a atualização da sua cópia de trabalho usando TortoiseSVN → Atualizar para a revisão...ao invés de TortoiseSVN → Atualizar. A atualização padrão incluirá todos os externos e manterá a profundidade configurada.

É recomendado que você obtenha apenas uma parte da estrutura de diretório do trunk, ou mais abaixo. Se você especificar o diretório principal da estrutura de diretório da URL você deverá acabar com o disco cheio já que uma vez que você obterá uma cópia da estrutura do repositório inteiro incluindo cada ramo e rótulo do seu projeto.

Exportando

Algumas vezes você vai querer criar uma cópia local sem nenhum dos diretórios .svn, ex. criar um arquivo compactado do código fonte. Leia “Exporting a Subversion Working Copy” para saber como fazer isto.

Submetendo Suas Alterações Para o Repositório

Enviar as alterações que você fez em sua cópia de trabalho é conhecido como Submeter as alterações. Mas antes de você submeter você deve ter certeza que sua cópia de trabalho está atualizada. Você pode usar tanto TortoiseSVN → Update diretamente. Ou você pode usar TortoiseSVN → Check for Modifications primeiro, para ver quais arquivos foram alterados localmente ou no servidor.

A Janela de Submissão

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....

 

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
For information on the coloring and overlays of the items according to their status, please see “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!

Submeter arquivos ou diretórios?

Quando você submete arquivos, a janela de submissão exibe apenas os arquivos que você selecionou. Quando você submete uma pasta, a janela de submissão irá exibir selecionado os arquivos modificados automaticamente. Se você se esqueceu de um novo arquivo que criou, submeter a pasta irá encontra-lo de qualquer forma. Submeter uma pasta não significa que todos os arquivos serão marcados como modificados; Isso apenas fará sua vida mais fácil.

Muitos arquivos não versionados na janela de submissão

Se você acha que a janela de submissão exibe muitos arquivos não versionados (arquivos gerados pelo compilador ou backups), existem muitas formas de lidar com isso. Você pode

• adicionar o arquivo (ou um caracter especial) para listar os arquivos para excluir nas configurações da página. Isto afetará toda a cópia de trabalho que você tem.
• adicionar o arquivo para a lista svn:ignore usando TortoiseSVN → Adicionar à lista de ignorados. Isto somente afetará o diretório no qual você configurou a propriedade svn:ignore. Usando a janela Propriedade do SVN, você pode alterar a propriedades svn:ignore para um diretório.
• add the file to the svn:global-ignores list using TortoiseSVN → Add to ignore list (recursively) This will affect the directory on which you set the svn:global-ignores property and all subfolders as well.

Read “Ignorando Arquivos e Diretórios” para mais informações

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.

Arrastar e Soltar

Você pode arrastar arquivos para dentro da janela de submissão de qualquer lugar, desde que as cópias de trabalho tenham sido obtidas do mesmo repositório. Por exemplo, você pode ter uma grande cópia de trabalho com inúmeras janelas do windows explorer abertas para olhar em pastas em diferentes lugares. Se você quiser evitar submeter do nível mais alto da estrutura de pastas (com uma longa lista de modificações) você pode abrir a janela de submissão para uma pasta e então arrastar os itens de outras janelas para incluir na mesma submissão atômica.
Você pode arrastar arquivos não versionados que residem em uma cópia de trabalho para uma janela de submissão e eles irão ser adicionados ao SVN automaticamente.
Arrastando arquivos da lista na parte de baixo da janela de submissão para o campo para edição da mensagem de log irá inserir os caminhos como texto dentro da caixa de edição. Isto é muito útil se você quer escrever mensagens de log da submissão que incluem os caminhos que foram afetados pela submissão.

Reparando Referência Externas Renomeadas

Algumas vezes arquivos são renomeados fora do Subversion, e eles aparecem na lista de arquivos como arquivos perdidos e como arquivos não versionados. Para evitar a perca do histório você precisa notificar o Subversion sobre a conexão entre os arquivos. Simplesmente selecione o arquivo antigo (perdido) e o arquivo nome (não versionado) e use a opção Menu de Contexto → Reparar movimento para identificar os dois arquivos como uma renomeação.

Reparando Cópias de Referências Externas

Se você fez uma cópia de um arquivo e esqueceu de usar o comando do SVN na cópia, você pode reparar a cópia e assim o novo arquivo não perderá seu histórico. Simplesmente selecione o arquivo antigo (normal ou modificado) e o nome arquivo (não versionado) e use Menu de Contexto → Reparar Cópia para identificar os dois arquivos como um cópia.

Lista de Alterações

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”.

Commit apenas de partes de arquivos

Às vezes você quer apenas cometer partes das alterações feitas em um arquivo. Tal situação geralmente acontece quando você está trabalhando em algo, mas, em seguida, um reparo urgente precisa ser confirmada, e essa correção passa a ser no mesmo arquivo que você está trabalhando.

clique direito sobre o arquivo e usa Menu de Contexto → Restaurar após cometer. Isto irá criar uma cópia do arquivo como ele é. Em seguida, você pode editar o arquivo, por exemplo, em TortoiseMerge e desfazer todas as mudanças que você não quer se comprometer. Depois de salvar as alterações que você pode cometer o arquivo.

Após o commit é feito, a cópia do arquivo é restaurado automaticamente, e você tem o arquivo com todas as suas modificações que não foram cometidos para trás.

Excluindo Itens de uma Lista de Submissões

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.

Registro de Mensagens 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.

 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.
A janela de mensagem de log também inclui um nome de arquivo e função de auto-completar. Isto usa expressões regulares para extrair nomes de classes e funções dos (textos dos) arquivos que você está submetendo, assim como os próprios nomes dos arquivos. Se uma palavra que você estiver digitando combinar com alguma coisa na lista (após você ter digitado pelo menos 3 caracteres, ou pressionado Ctrl+Espaço), uma lista aparece, permitindo que você selecione o nome completo. As expressões regulares disponibilizadas com o TortoiseSVN são mantidas na pasta bin no diretório de instalação do TortoiseSVN. Você pode definir suas próprias expressões regulares e guardá-las em %APPDATA%\TortoiseSVN\autolist.txt. É claro que sua auto lista privada não será sobrescrita quando você atualizar sua instalação do TortoiseSVN. se você não é familiarizado com expressões regulares, dê uma olhada na introdução em http://pt.wikipedia.org/wiki/Expressões_regulares, e a documentação online e tutorial em 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.
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.

Propriedades de Pastas Especiais

Existem muitas propriedades especiais nos diretórios que podem ser usados para dar mais controle sobre a formatação das mensagens de log na submissão e o idioma usado pelo módulo de correção ortográfica. Leia “Configurações do Projeto” para mais informações.

Integração com Ferramentas de Rastreamento de Erros

se você ativou o sistema de rastreamento de erros, você pode configurar um ou mais Controles no campo do texto Bug-ID / Issue-Nr:. Multiplos controles devem ser separados com virgula. Uma alternativa, se você está usando um controle de rastreamento de erros baseado em expressões regulares, você pode adicionar a referência ao seu controle como parte da mensagem de log. Aprenda mais sobre isso em “Integration with Bug Tracking Systems / Issue Trackers”.

Progresso da Submissão

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

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

Azul

Submetendo uma modificação.

Roxo

Submetendo uma nova adição.

Vermelho escuro

Submetendo um exclusão ou substituição.

Preto

Todos os outros itens.

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

Atualizar sua Cópia de Trabalho com mudanças feitas por outros

 

Periodicamente, você deve garantir que mudanças feitas por outros sejam incorporadas na sua cópia de trabalho. O processo de pegar as mudanças do servidor para sua cópia local é conhecido como atualização. A atualização pode ser feita em arquivos, uma seleção de arquivos, ou recursivamente na herarquia inteira de diretórios. Para atualizar, selecione os arquivos e/ou diretórios que quiser, clique com o botão direito e selecione TortoiseSVN → Atualizar no menu de contexto do explorer. Uma janela aparecerá mostrando o progresso da atualização em tempo real. As mudanças feitas por outros serão consolidadas com seus arquivos, mantendo quaisquer mudanças que você possa ter feito nos mesmos arquivos. O repositório não é afetado por uma atualização.

A janela de progresso faz uso de código de cores para sublinhar diferentes ações de atualização

Roxo

Novo item adicionado à CT.

Vermelho escuro

Item redundante apagado da sua CT, ou item substituído na sua CT.

Verde

Mudanças no repositório consolidadas com suas mudanças locais com sucesso

Vermelho vivo

Mudanças no repositório consolidadas com mudanças locais, resultando em conflitos que você precisa resolver.

Preto

Item inalterado em sua CT atualizado com nova versão do repositório.

Este é o esquema padrão de cores, mas você pode personalizar as cores usando a janela de configurações. Acesse “TortoiseSVN Colour Settings” para mais informações.
Se você receber quaisquer conflitos durante uma atualização (isso pode acontecer se outras pessoas alteraram as mesmas linhas no mesmo arquivo que você e essas mudanças não são compatíveis) então a janela mostra esses conflitos em vermelho. Você pode efetuar um clique duplo nessas linhas para começar a ferramenta consolidação externa para resolver esses conflitos.
Quando a atualização estiver completa, a janela de progresso mostrará um sumário do número de itens atualizados, adicionados, removidos, em conflito, etc. abaixo da lista de arquivos. Esta informação pode ser copiada para a área de transferência usando Ctrl+C.
O comando padrão de atualização não tem opções e apenas atualiza sua cópia de trabalho para a revisão HEAD do repositório , que é o caso de uso mais comum. Se você quiser mais controle sobre o processo de atualização , você deve usar TortoiseSVN → Atualizar para revisão ... em vez disso . Isso permite que você atualize sua cópia de trabalho para uma revisão específica , não só para o mais recente. Suponha que a sua cópia de trabalho está na revisão 100, mas você quer que refletem o estado que tinha na revisão 50 - então simplesmente atualizar a revisão 50 .
Na mesma caixa de diálogo , você também pode escolher a profundidade em que a atualização da pasta atual. Os termos usados ​​são descritos em " Profundidade da Obtenção " . A profundidade padrão é Cópia de trabalho , o que preserva a configuração de profundidade existente. Você também pode definir a profundidade pegajoso que significa actualizações subsequentes usará essa nova profundidade , ou seja, que a profundidade é então usada como a profundidade padrão.
Para torná-lo mais fácil de incluir ou excluir itens específicos do check-out clique nos itens escolher ... botão. Isso abre uma nova janela onde você pode verificar todos os itens que você deseja em sua cópia de trabalho e desmarque todos os itens que você não quer .
Você também pode escolher se deseja ignorar quaisquer projetos externos na atualização (ou seja, projetos referenciados usando svn : externals ) .

Cuidado

Se você atualizar um arquivo ou pasta para uma versõa específica, você não deve fazer mudanças nesses arquivos. Você receberá mensagens de erro do tipo “desatualizados” quando tentar submetê-las! Se você quiser desfazer mudanças feitas em um arquivo e começar novamente de uma versão anterior, você pode reverter para uma versão anterior a partir da janela de log de revisões. Dê uma olhada em “Roll back (Undo) revisions in the repository” para mais instruções, e métodos alternativos.

Atualizar para Revisão pode ser ocasionalmente útil para ver como seu projeto parecia em um momento anterior de sua história. Mas de modo geral, atualizar arquivos individualmente para uma versão anterior não é uma boa idéia porque deixa sua cópia de trabalho em estado inconsistente. Se o arquivo que você está atualizando mudou de nome, você pode até descobrir que o arquivo simplesmente desaparece da sua cópia de trabalho porque não havia arquivo com aquele nome na revisão anterior. Você também deve notar que o item terá umrevestimento verde normal, para que seja indistinguível dos arquivos que estão atualizados com a última versão.
Se você simplesmente quer uma cópia local de uma versão anterior de um arquivo é melhor usar o comando Menu de Contexto → Salvar revisão para... a partir da janela de log daquele arquivo.

Múltiplos Arquivos/Diretórios

Se você selecionar múltiplos arquivos e pastas no explorer e depois selecionar Atualizar, todos estes arquivos/pastas serão atualizados um a um. O TortoiseSVN garantirá que todos arquivos/pastas que são do mesmo repositório serão atualizados para a mesma revisão! Mesmo se entre estas atualizações uma outra submissão tenha ocorrido.

Resolvendo Conflitos

Em algum momento você poderá se deparar com um conflito quando for atualizar/unificar seus arquivos desde o repositório ou quando você for modificar sua cópia local para uma URL diferente. Existem dois tipos de conflitos:

conflitos de arquivo

Um conflito de arquivo ocorre se dois (ou mais) desenvolvedores modificam as mesmas linhas de um arquivo.

conflitos de estrutura

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.

Conflitos de Arquivo

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:

filename.ext.mine

Este é seu arquivo tal como existia em sua cópia local antes de tê-la atualizado - ou seja, sem indicações de conflito. Este arquivo contém as modificações mais recentes e nada mais.

filename.ext.rREVANT

Este é o arquivo que serviu de revisão BASE antes de atualizar sua cópia local. Ou seja, é o arquivo que você assinalou para controlar antes de efetuar as modificações.

filename.ext.rNOVAREV

Este é o arquivo que o cliente Subversion acabou de receber do servidor quando você atualizou sua cópia local. Este arquivo corresponde à revisão HEAD do repositório.

You can either launch an external merge tool / conflict editor with TortoiseSVN → Edit Conflicts or you can use any text editor to resolve the conflict manually. You should decide what the code should look like, do the necessary changes and save the file. Using a merge tool such as TortoiseMerge or one of the other popular tools is generally the easier option as they generally present the files involved in a 3-pane view and you don't have to worry about the conflict markers. If you do use a text editor then you should search for lines starting with the 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.

Conflitos de Propriedade

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.

Conflitos de Estrutura

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.

Exclusão local, alteração na atualização

1. Desenvolvedor A modifica Foo.c e o submete para o repositório.
2. Desenvolvedor B simultaneamente moveu Foo.c para Bar.c em sua cópia local ou simplesmente eliminou Foo.c ou a pasta que o continha.

Uma atualização da cópia de trabalho do desenvolvedor B resulta num conflito de estrutura:

• Foo.c foi eliminado da cópia de trabalho mas está marcado com um conflito de estrutura.
• Se o conflito resulta por ter renomeado ao invés de ter eliminado então Bar.c estará marcado como adicionado mas não irá conter as modificações do desenvolvedor A.

Desenvolvedor B agora deverá escolher se mantém ou não as modificações do desenvolvedor A. No caso de um arquivo ter sido renomeado, ele poderá submeter as modificações de Foo.c para o arquivo renomeado Bar.c. No caso de simples arquivo ou pasta deletada, ele poderá escolher entre manter o item com as modificações do desenvolvedor A e descartar o arquivo eliminado. Ou então, poderá marcar o conflito como resolvido sem tomar qualquer atitude e efeticamente irá descartar as modificações do desenvolvedor A.
A caixa de diálogo Editar Conflito possibilita submeter modificações se for possível encontrar o arquivo original do renomeado Bar.c. Dependendo de onde a atualização ocorreu, poderá não ser possível encontrar o arquivo fonte.

Alteração local, exclusão na atualização

1. Desenvolvedor A move Foo.c para Bar.c e submete para o repositório.
2. Desenvolvedor B modifica Foo.c na sua cópia de trabalho.

Ou no caso de um diretório movido ...

1. Desenvolvedor A move a pasta que o continha de FooFolder para BarFolder e submete para o repositório.
2. Desenvolvedor B modifica Foo.c na sua cópia de trabalho.

Uma atualização na cópia de trabalho do desenvolvedor B resulta num conflito de estrutura. Para um simples conflito de arquivo:

• Bar.c é adicionado na cópia de trabalho como um arquivo normal.
• Foo.c é assinalado como adicionado (com histórico) e indica um conflito de estrutura.

Para um conflito de pasta:

• BarFolder é adicionada para a cópia de trabalho como uma pasta normal.
• FooFolder é assinalada como adicionada (com histórico) e indica um conflito de estrutura.
  Foo.c é assinalado como modificado.

Desenvolvedor B agora terá que decidir o que fazer com a reorganização do desenvolvedor A e submeter suas modificações para o arquivo correspondente na nova estrutura ou simplesmente reverter as modificações do desenvolvedor A e manter o arquivo local.
Para submeter suas modificações locais com o RESHUFFLE, o desenvolvedor B primeiro precisará saber para qual nome o arquivo em conflito Foo.c foi renomeado ou movido no repositório. Isto pode ser feito fazendo uso da caixa de diálogo do Log. As modificações poderão ser então submetidas manualmente - uma vez que não há maneira de automatizar ou simplificar esse processo. Uma vez que as modificações tenham sido PORTED ACROSS, o PATH em conflito será redundante e poderá ser eliminado. Neste caso, utilize o botão Remover da caixa de diálogo do Editor de Conflitos para limpar e assinalar o conflito como resolvido.
Se o Desenvolvedor B decide que as modificações do Desenvolvedor A estão erradas então ele deverá escolher o botão Manter na caixa de diálogo do Editor de Conflitos. Desta forma, o conflito no arquivo ou pasta será assinalado como resolvido mas as modificações do Desenvolvedor A precisarão ser removidas manualmente. Mais uma vez, a caixa de diálogo do Log auxilia para identificar o que foi movido.

Exclusão local, exclusão na atualização

1. Desenvolvedor A move Foo.c para Bar.c e submete para o repositório.
2. Desenvolvedor B move o arquivo Foo.c para Bix.c.

Uma atualização da cópia de trabalho do desenvolvedor B resulta num conflito de estrutura:

• Bix.c é marcado como adicionado com histórico.
• Bar.c é adicionado na cópia local com status "normal".
• Foo.c é marcado como eliminado e possui um conflito de estrutura.

Para resolver este conflito, Desenvolvedor B terá que descobrir para qual nome o arquivo em conflito Foo.c foi renomeado/movido no repositório. Isto pode ser feito usando a caixa de diálogo do log.
Em seguida, o Desenvolvedor B terá que decidir se o novo nome do arquivo Foo.c será mantido - se aquele dado pelo Desenvolvedor A ou se aquele renomeado por ele mesmo.
Depois que o Desenvolvedor B tenha manualmente solucionado o conflito, o conflito de estrutura deve ser marcado como "resolvido", usando o botão apropriado na caixa de diálogo do Editor de Conflitos.

Inexistência local, alteração na atualização

1. Desenvolvedor A trabalhando no trunk, modifica o arquivo Foo.c e submete o arquivo para o repositório
2. Desenvolvedor B trabalhando com o branch, move e renomeia o arquivo Foo.c para Bar.c e submete a alteração para o repositório

A atualização do Desenvolvedor A no trunk e a do Desenvolvedor B no branch, resulta num conflito de estrutura:

• Bar.c já está na cópia de trabalho com status "norma"'.
• Foo.c está assinalado como "desaparecido" e com um conflito de estrutura.

Para solucionar este conflito, o Desenvolvedor B terá que marcar esse arquivo como "resolvido" na caixa de diálogo do Editor de Conflitos - o qual irá removê-lo da lista de conflitos. O Desenvolvedor B terá então que decidir se deve copiar o arquivo Foo.c "desaparecido" do repositório para a cópia de trabalho ou então se deve atualizar as modificações do Desenvolvedor A no arquivo Foo.c para o arquivo renomeado como Bar.c ou então se deve ignorar as modificações marcando o conflito como resolvido e fazer nada mais.
Note que se você copiar o arquivo "desaparecido" do repositório e então marcá-lo como resolvido, esse arquivo copiado será removido novamente. Você deve primeiro, resolver o conflito.

Alteração local, exclusão na unificação

1. Desenvolvedor A trabalhando em trunk move Foo.c para Bar.c e o submete para o repositório.
2. Desenvolvedor B trabalhando no branch modifica o arquivo Foo.c e o submete para o repositório.

Existe uma situação equivalente para a movimentação de pastas, mas isto ainda não é detectado pela Subversão 1.6...

1. Desenvolvedor A trabalhando no trunk move a pasta FooFolder para BarFolder e submete a alteração para o repositório.
2. Desenvolvedor B trabalhando no branch modifica o arquivo Foo.c em sua cópia de trabalho.

A atualização do Desenvolvedor A no trunk e a do Desenvolvedor B no branch, resulta num conflito de estrutura:

• Bar.c é marcado como adicionado.
• Foo.c é marcado como modificado com um conflito de estrutura.

Desenvolvedor B agora terá que decidir o que fazer com a reorganização do desenvolvedor A e submeter suas modificações para o arquivo correspondente na nova estrutura ou simplesmente reverter as modificações do desenvolvedor A e manter o arquivo local.
Para submeter suas modificações locais com o RESHUFFLE, o Desenvolvedor B primeiro precisará saber para qual nome o arquivo em conflito Foo.c foi renomeado ou movido no repositório. Isto pode ser feito fazendo uso da caixa de diálogo do Log. O Editor de Conflitos somente exibirá o log da cópia de trabalho, uma vez que ele não sabe qual PATH foi usado na submissão - por isso você deverá descobrir este detalhe. As modificações deverão ser submetidas manualmente uma vez que não há maneira de automatizar ou mesmo simplificar esse processo. Uma vez que as alterações tenham sido realizadas, o PATH em conflito é redundante e poderá ser eliminado. Neste caso, utilize o botão Remover da caixa de diálogo do Editor de Conflitos para limpar e marcar o conflito como resolvido.
Se o Desenvolvedor B decide que as modificações do Desenvolvedor A estão erradas então ele deverá escolher o botão Manter na caixa de diálogo do Editor de Conflitos. Desta forma, o conflito no arquivo ou pasta será assinalado como resolvido mas as modificações do Desenvolvedor A precisarão ser removidas manualmente. Mais uma vez, a caixa de diálogo de log do MERGE SOURCE auxilia para identificar o que foi movido.

Exclusão local, exclusão na unificação

1. Desenvolvedor A trabalhando em trunk move Foo.c para Bar.c e o submete para o repositório.
2. Desenvolvedor B trabalhando em um ramo, move e renomeia o arquivo Foo.c para Bix.c e submete a alteração para o repositório.

A atualização do Desenvolvedor A no trunk e a do Desenvolvedor B no branch, resulta num conflito de estrutura:

• Bix.c é marcado com Status de normal (não modificado).
• Bar.c é marcado como adicionado com histórico.
• Foo.c é marcado como inexistente e como tendo um conflito de estrutura.

Para resolver este conflito, Desenvolvedor B terá que descobrir para qual nome o arquivo em conflito Foo.c foi renomeado/movido no repositório. Isto pode ser feito usando a caixa de diálogo do MERGE SOURCE. O Editor de Conflitos apenas exibirá o log da cópia de trabalho, uma vez que não sabe qual PATH foi usado na submissão e portanto você deverá descobrir esse detalhe.
Em seguida, o Desenvolvedor B terá que decidir se o novo nome do arquivo Foo.c será mantido - se aquele dado pelo Desenvolvedor A ou se aquele renomeado por ele mesmo.
Depois que o Desenvolvedor B tenha manualmente solucionado o conflito, o conflito de estrutura deve ser marcado como "resolvido", usando o botão apropriado na caixa de diálogo do Editor de Conflitos.

Outros conflitos de estrutura

Há outros casos em que são identificados como conflitos de estrutura simplesmente porque o conflito envolve um diretório ao invés de um arquivo. Por exemplo, se você adicionar um diretório com o mesmo nome no tronco e no ramo e então tentar combiná-los você terá um conflito de estrutura.