[svnbook-pt-br commit] r356 - trunk/book
codesite-noreply at google.com
codesite-noreply at google.com
Wed Dec 24 21:09:56 CST 2008
Author: mfandrade
Date: Wed Dec 24 18:29:43 2008
New Revision: 356
Modified:
trunk/book/ch05-repository-admin.xml
Log:
Tradução do capítulo 5, ""Administração do Repositório", seção "Manutenção
do Repositório", subseção "Filtrando Histórico do Repositório".
Modified: trunk/book/ch05-repository-admin.xml
==============================================================================
--- trunk/book/ch05-repository-admin.xml (original)
+++ trunk/book/ch05-repository-admin.xml Wed Dec 24 18:29:43 2008
@@ -2082,8 +2082,8 @@
<para>Outro truque efetivo que você pode executar com esta opção
<option>--incremental</option> envolve anexar um novo intervalo
- de revisõe despejadas para um arquivo de despejo existente. Por
- exemplo, você pode ter um script de hook
+ de revisões despejadas para um arquivo de despejo existente.
+ Por exemplo, você pode ter um script de hook
<literal>post-commit</literal> que simplesmente anexe o despejo
do repositório de uma única revisão que senha disparado o
script. Ou você pode ter um script que seja executado
@@ -2154,81 +2154,85 @@
<!-- ===============================================================
-->
<sect2 id="svn.reposadmin.maint.filtering">
- <title>Filtering Repository History</title>
+ <title>Filtrando o Histórico do Repositório</title>
- <para>Since Subversion stores your versioned history using, at
- the very least, binary differencing algorithms and data
- compression (optionally in a completely opaque database
- system), attempting manual tweaks is unwise, if not quite
- difficult, and at any rate strongly discouraged. And once
- data has been stored in your repository, Subversion
- generally doesn't provide an easy way to remove that data.
+ <para>Como o Subversion armazena seu histórico versionado usando,
+ no mínimo, algorítmos de diferenciação binária e compactação de
+ dados (opcionalmente em um sistema de base de dados
+ completamente opaco), tentar fazer qualquer ajuste manual é
+ imprudente, para não dizer difícil, e pelo menos fortemente
+ desencorajado. E uma vez que os dados forem armazenados em seu
+ repositório, o Subversion geralmente não dispõe de uma maneira
+ fácil de remover estes dados.
<footnote>
- <para>That's rather the reason you use version control at
- all, right?</para>
+ <para>Que é precisamente a razão para usar um sistema de
+ controle de versão, certo?</para>
</footnote>
- But inevitably, there will be times when you would like to
- manipulate the history of your repository. You might need
- to strip out all instances of a file that was accidentally
- added to the repository (and shouldn't be there for whatever
- reason).
+ Mas inevitavelmente, há algumas vezes que você poderia querer
+ manipular o histórico de seu repositório. Você pode precisar
+ remover todas as instâncias de um arquivo que fora
+ acidentalmente adicionado ao repositório (e não deveria estar
+ ali de forma nenhuma).
<footnote>
- <para>Conscious, cautious removal of certain bits of
- versioned data is actually supported by real use-cases.
- That's why an <quote>obliterate</quote> feature has been
- one of the most highly requested Subversion features,
- and one which the Subversion developers hope to soon
- provide.</para>
+ <para>Conscientemente, a remoção cuidadosa de certas porções
+ de dados versionados é necessária atualmente em alguns casos
+ de uso reais. Isso é porque o recurso de
+ <quote>obliteração</quote> tenha sido um dos recursos mais
+ requisitados para o Subversion, e um dos quais os
+ desenvolvedores do Subversion esperam disponibilizar em
+ breve.</para>
</footnote>
- Or, perhaps you have multiple projects sharing a
- single repository, and you decide to split them up into
- their own repositories. To accomplish tasks like this,
- administrators need a more manageable and malleable
- representation of the data in their repositories—the
- Subversion repository dump format.</para>
-
- <para>As we described in <xref
- linkend="svn.reposadmin.maint.migrate" />, the
- Subversion repository dump format is a human-readable
- representation of the changes that you've made to your
- versioned data over time. You use the <command>svnadmin
- dump</command> command to generate the dump data, and
- <command>svnadmin load</command> to populate a new
- repository with it (see <xref
- linkend="svn.reposadmin.maint.migrate"/>). The great thing
- about the human-readability aspect of the dump format is
- that, if you aren't careless about it, you can manually
- inspect and modify it. Of course, the downside is that if
- you have three years' worth of repository activity
- encapsulated in what is likely to be a very large dump file,
- it could take you a long, long time to manually inspect and
- modify it.</para>
-
- <para>That's where <command>svndumpfilter</command> becomes
- useful. This program acts as path-based filter for
- repository dump streams. Simply give it either a list of
- paths you wish to keep, or a list of paths you wish to not
- keep, then pipe your repository dump data through this
- filter. The result will be a modified stream of dump data
- that contains only the versioned paths you (explicitly or
- implicitly) requested.</para>
-
- <para>Let's look a realistic example of how you might use this
- program. We discuss elsewhere (see <xref
- linkend="svn.reposadmin.projects.chooselayout"/>) the
- process of deciding how to choose a layout for the data in
- your repositories—using one repository per project or
- combining them, arranging stuff within your repository, and
- so on. But sometimes after new revisions start flying in,
- you rethink your layout and would like to make some changes.
- A common change is the decision to move multiple projects
- which are sharing a single repository into separate
- repositories for each project.</para>
-
- <para>Our imaginary repository contains three projects:
- <literal>calc</literal>, <literal>calendar</literal>, and
- <literal>spreadsheet</literal>. They have been living
- side-by-side in a layout like this:</para>
+ Ou, talvez, você tenha múltiplos projetos compartilhando um
+ único repositório, e você decida dividí-lo em seus próprios
+ repositórios. Para cumprir uma tarefa como esta, os
+ administradores precisam de uma representação mais gerenciável e
+ flexível dos dados em seus repositórios—o formato de
+ despejo do repositório do Subversion.</para>
+
+ <para>Como descrevemos em <xref
+ linkend="svn.reposadmin.maint.migrate" />, o repositório do
+ Subversion é uma representação legível por humanos das
+ alterações que você tem feito em seus dados versionados ao longo
+ do tempo. Você usa o comando <command>svnadmin
+ dump</command> para gerar dados de despejo, e o
+ <command>svnadmin load</command> para popular um novo
+ repositório com eles (veja <xref
+ linkend="svn.reposadmin.maint.migrate"/>). A grande coisa sobre
+ o aspecto da legibilidade do formato de despejo é que, se você
+ não tiver cuidado sobre isso, você pode manualmente
+ inspecioná-lo e modificá-lo. É claro, o lado negativo é que se
+ você tiver três anos de atividade no repositório encapsulados no
+ que pode ser um arquivo de despejo muito grande, isso levaria
+ muito, muito tempo para inspecioná-lo e modificá-lo
+ manualmente.</para>
+
+ <para>É aí que entra o comando <command>svndumpfilter</command>.
+ Este programa atua como um filtro baseado em caminhos para
+ fluxos de despejo do repositório. Simplesmhete lhe dê ou uma
+ lista de caminhos que você quer manter, ou uma lista de caminhos
+ que você não quer manter, e então canalize seu fluxo de dados de
+ despejo do repositório para este filtro. O resultado será um
+ fluxo de dados de despejo que contenha apenas os caminhos
+ versionados que você requisitou (explicita ou
+ implicitamente).</para>
+
+ <para>Vamos dar uma olhada em um exemplo realista de como você
+ poderia usar este programa. Discutimos mais sobre o processo de
+ decidir como escolher a estrutura para os dados de seu
+ repositório (veja <xref
+ linkend="svn.reposadmin.projects.chooselayout"/>)—utilizando
+ um repositório por projeto ou combinando eles, arranjando coisas
+ dentro de seu repositório, e daí por diante. Mas algumas vezes
+ depois que novas revisões começam a ocorrer, você reconsidera a
+ estrutura de seu repositório e gostaria de fazer algumas
+ modificações. Uma modificação comum é a decisão de mover
+ múltiplos projetos que estejam compartilhando um único
+ repositório em repositórios separados para cada projeto.</para>
+
+ <para>Nosso repositório imaginário contém três projetos:
+ <literal>calc</literal>, <literal>calendar</literal>, e
+ <literal>spreadsheet</literal>. Eles têm convivido lado-a-lado
+ em uma estrutura como esta:</para>
<screen>
/
@@ -2246,8 +2250,8 @@
tags/
</screen>
- <para>To get these three projects into their own repositories,
- we first dump the whole repository:</para>
+ <para>Para pôr estes três projetos em seus próprios repositórios,
+ primeiro despejamos todo o repositório:</para>
<screen>
$ svnadmin dump /path/to/repos > repos-dumpfile
@@ -2259,9 +2263,9 @@
$
</screen>
- <para>Next, run that dump file through the filter, each time
- including only one of our top-level directories, and
- resulting in three new dump files:</para>
+ <para>Depois, passamos o arquivo de despejo por um filtro, a cada
+ vez incluindo apenas um de nossos diretórios de alto nível, e
+ resultando em três novos arquivos de despejo:</para>
<screen>
$ svndumpfilter include calc < repos-dumpfile > calc-dumpfile
@@ -2273,22 +2277,22 @@
$
</screen>
- <para>At this point, you have to make a decision. Each of
- your dump files will create a valid repository,
- but will preserve the paths exactly as they were in the
- original repository. This means that even though you would
- have a repository solely for your <literal>calc</literal>
- project, that repository would still have a top-level
- directory named <filename>calc</filename>. If you want
- your <filename>trunk</filename>, <filename>tags</filename>,
- and <filename>branches</filename> directories to live in the
- root of your repository, you might wish to edit your
- dump files, tweaking the <literal>Node-path</literal> and
- <literal>Node-copyfrom-path</literal> headers to no longer have
- that first <filename>calc/</filename> path component. Also,
- you'll want to remove the section of dump data that creates
- the <filename>calc</filename> directory. It will look
- something like:</para>
+ <para>Neste ponto, nós tomamos uma decisão. Cada um de seus
+ arquivos de despejo vai criar um repositório válido, mas ainda
+ preservando os caminhos exatamente como eram no repositório
+ original. Isto quer dizer que mesmo que você tivesse um
+ repositório apenas para seu projeto <literal>calc</literal>,
+ este repositório ainda assim teria um diretório de alto nível
+ chamado <filename>calc</filename>. Se você quiser que seus
+ diretórios <filename>trunk</filename>, <filename>tags</filename>,
+ e <filename>branches</filename> fiquem na raiz de seu
+ repositório, você poderia querer editar seus arquivos de
+ despejo, ajustando os cabeçalhos <literal>Node-path</literal> e
+ <literal>Node-copyfrom-path</literal> para que não tenham mais o
+ <filename>calc/</filename> como parte do caminho. Também, você
+ vai querer remover a seção de dados de despejo que cria o
+ diretório <filename>calc</filename>. Ela será algo parecido
+ com:</para>
<screen>
Node-path: calc
@@ -2299,17 +2303,17 @@
</screen>
<warning>
- <para>If you do plan on manually editing the dump file to
- remove a top-level directory, make sure that your editor is
- not set to automatically convert end-of-line characters to the
native
- format (e.g. \r\n to \n), as the content will then not agree
- with the metadata. This will render the dump file
- useless.</para>
+ <para>Se você planeja editar manualmente o arquivo de despejo
+ para remover um diretório de alto nível, certifique-se de que
+ seu editor não esteja configurado para converter caracteres
+ de quebras de linhas para o formato nativo (p.ex., \r\n para
+ \n), pois assim o conteúdo não irá correspondem aos metadados.
+ Isto vai inutilizar o arquivo de despejo.</para>
</warning>
- <para>All that remains now is to create your three new
- repositories, and load each dump file into the right
- repository:</para>
+ <para>Tudo o que resta agora é criar seus três novos repositórios,
+ e carregar cada arquivo de despejo para dentro do repositório
+ correto:</para>
<screen>
$ svnadmin create calc; svnadmin load calc < calc-dumpfile
@@ -2330,53 +2334,54 @@
$
</screen>
- <para>Both of <command>svndumpfilter</command>'s subcommands
- accept options for deciding how to deal with
- <quote>empty</quote> revisions. If a given revision
- contained only changes to paths that were filtered out, that
- now-empty revision could be considered uninteresting or even
- unwanted. So to give the user control over what to do with
- those revisions, <command>svndumpfilter</command> provides
- the following command-line options:</para>
+ <para>Ambos os subcomandos do <command>svndumpfilter</command>
+ aceitam opções para decidir como lidar com revisões
+ <quote>vazias</quote>. Se uma dada revisão contiver apenas
+ modificações em caminhos que foram filtrados, então as revisões
+ que não foram filtradas podem ser vistas como desinteressantes
+ ou mesmo indesejadas. Assim, para deixar que o usuário controle
+ o que fazer com tais revisões, o
+ <command>svndumpfilter</command> dispõe das seguintes opções de
+ linhas de comando:</para>
<variablelist>
<varlistentry>
<term><option>--drop-empty-revs</option></term>
<listitem>
- <para>Do not generate empty revisions at all—just
- omit them.</para>
+ <para>Nunca gera revisões vazias—apenas as omite.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--renumber-revs</option></term>
<listitem>
- <para>If empty revisions are dropped (using the
- <option>--drop-empty-revs</option> option), change the
- revision numbers of the remaining revisions so that
- there are no gaps in the numeric sequence.</para>
+ <para>Se as revisões vazias forem removidas (usando a opção
+ <option>--drop-empty-revs</option>), modifica os números
+ de revisão das revisões remanescentes de tal forma que não
+ fiquem partes faltando na sequência numérica.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--preserve-revprops</option></term>
<listitem>
- <para>If empty revisions are not dropped, preserve the
- revision properties (log message, author, date, custom
- properties, etc.) for those empty revisions.
- Otherwise, empty revisions will only contain the
- original datestamp, and a generated log message that
- indicates that this revision was emptied by
+ <para>Se as revisões vazias não forem removidas, preserva as
+ propriedades de revisão (mensagem de log, autor, data,
+ propriedades específicas, etc.) para essas revisões
+ vazias. Do contrário, revisões vazias sempre irão conter
+ a datação original, e uma mensagem de log gerada que
+ indica que aquela revisão foi esvaziada pelo
<command>svndumpfilter</command>.</para>
</listitem>
</varlistentry>
</variablelist>
- <para>While <command>svndumpfilter</command> can be very
- useful, and a huge timesaver, there are unfortunately a
- couple of gotchas. First, this utility is overly sensitive
- to path semantics. Pay attention to whether paths in your
- dump file are specified with or without leading slashes.
- You'll want to look at the <literal>Node-path</literal> and
- <literal>Node-copyfrom-path</literal> headers.</para>
+ <para>Ainda que o <command>svndumpfilter</command> possa ser
+ bem útil e economizar bastamte tempo, infelizmente ele também
+ pode representar uma porção de pegadinha. Primeiro, este
+ utilitário é altamente sensível à semântica dos caminhos.
+ Preste atenção se os caminhos em seu arquivo de despejo estão
+ especificados com ou sem uma barra final. Você vai querer
+ checar os cabeçalhos <literal>Node-path</literal> e
+ <literal>Node-copyfrom-path</literal>.</para>
<screen>
…
@@ -2384,61 +2389,66 @@
…
</screen>
- <para>If the paths have leading slashes, you should
- include leading slashes in the paths you pass to
- <command>svndumpfilter include</command> and
- <command>svndumpfilter exclude</command> (and if they don't,
- you shouldn't). Further, if your dump file has an inconsistent
- usage of leading slashes for some reason,
+ <para>Se os caminhos tiverem uma barra final, você deveria incluir
+ barras nos caminhos que passar para o
+ <command>svndumpfilter include</command> e
+ <command>svndumpfilter exclude</command> (e se a barra não
+ existir, você não deve incluí-la). Além disso, se seu arquivo
+ de despejo, por alguma razão, estiver usando essas barras de
+ forma inconsistente,
<footnote>
- <para>While <command>svnadmin dump</command> has a
- consistent leading slash policy—to not include
- them—other programs which generate dump data might
- not be so consistent.</para>
+ <para>Ainda que o <command>svnadmin dump</command> obedeça a
+ uma política de uso consistente de uso desse sinal de
+ barra—que é nunca incluí-la—outros programas que
+ geram dados de despejo podem não ter a mesma
+ consistência.</para>
</footnote>
- you should probably normalize those paths so they all
- have, or lack, leading slashes.</para>
+ você provavelmente deveria normalizar estes caminhos de forma a
+ manter sempre, ou remover sempre, o sinal de barra final.</para>
- <para>Also, copied paths can give you some trouble.
- Subversion supports copy operations in the repository, where
- a new path is created by copying some already existing path.
- It is possible that at some point in the lifetime of your
- repository, you might have copied a file or directory from
- some location that <command>svndumpfilter</command> is
- excluding, to a location that it is including. In order to
- make the dump data self-sufficient,
- <command>svndumpfilter</command> needs to still show the
- addition of the new path—including the contents of any
- files created by the copy—and not represent that
- addition as a copy from a source that won't exist in your
- filtered dump data stream. But because the Subversion
- repository dump format only shows what was changed in each
- revision, the contents of the copy source might not be
- readily available. If you suspect that you have any copies
- of this sort in your repository, you might want to rethink
- your set of included/excluded paths, perhaps including the
- paths that served as sources of your troublesome copy
- operations, too.</para>
-
- <para>Finally, <command>svndumpfilter</command> takes path
- filtering quite literally. If you are trying to copy the
- history of a project rooted at
- <filename>trunk/my-project</filename> and move it into a
- repository of its own, you would, of course, use the
- <command>svndumpfilter include</command> command to keep all
- the changes in and under
- <filename>trunk/my-project</filename>. But the resulting
- dump file makes no assumptions about the repository into
- which you plan to load this data. Specifically, the dump
- data might begin with the revision which added the
- <filename>trunk/my-project</filename> directory, but it will
- <emphasis>not</emphasis> contain directives which would
- create the <filename>trunk</filename> directory itself
- (because <filename>trunk</filename> doesn't match the
- include filter). You'll need to make sure that any
- directories which the new dump stream expect to exist
- actually do exist in the target repository before trying to
- load the stream into that repository.</para>
+ <para>E também, caminhos copiados podem lhe dar algum problema. O
+ Subversion suporta operações de cópia no repositório, sendo que
+ um novo caminho é criado copiando-se algum caminho já existente.
+ É possível que em algum ponto do ciclo de vida de seu
+ repositório, você pode ter copiado um arquivo ou diretório a
+ partir de algum local que o <command>svndumpfilter</command>
+ <!-- TODO: hummm.... rever esta tradução -->
+ desconsidere (um local excluído) para um local levado em conta
+ (um local incluído). Para fazer com que os dados despejados
+ sejam auto-suficientes, o <command>svndumpfilter</command> ainda
+ precisa mostrar a adição do novo caminho—incluindo o
+ conteúdo de alguns arquivos criados pela cópia—e que não
+ signifiquem que a adição foi uma cópia a partir de uma origem
+ que não existia em seu fluxo de dados de despejo filtrados. Mas
+ como o formato de despejo do repositório do Subversion apenas
+ contém o que foi modificado em cada uma das revisões, o conteúdo
+ de origem de sua cópia pode não estar prontamente disponível.
+ Se você suspeitar que você tem cópias desse tipo em seu
+ repositório, você pode querer reconsiderar suas configurações de
+ caminhos incluídos/excluídos, talvez incluindo os caminhos
+ usados como origens de suas operações de cópia problemáticas
+ também.</para>
+
+ <para>Por fim, o <command>svndumpfilter</command> realiza a
+ filtragem baseada em caminhos de forma quase que literal. Se
+ você está tentando copiar o histórico de um projeto hospedado
+ sob <filename>trunk/my-project</filename> e movê-lo para dentro
+ de um repositório próprio, você deveria, obviamente, usar o
+ comando <command>svndumpfilter include</command> para incluir
+ todas as modificações dentro de
+ <filename>trunk/my-project</filename>. Mas o arquivo de despejo
+ resultando não faz presunções sobre o repositório no qual você
+ planeja carregar estes dados. Especificamente, os dados
+ despejados podem começar com o número de revisão no qual
+ foram adicionados no diretório
+ <filename>trunk/my-project</filename>, mas ainda
+ <emphasis>não</emphasis> vão conter diretivas que poderiam
+ criar o diretório <filename>trunk</filename> em si (já que o
+ <filename>trunk</filename> não corresponde ao filtro de
+ inclusão). Você precisará ter certeza de que quaisquer
+ diretórios os quais os novos fluxos de despejo esperam existir
+ atualmente existam no repositório destino antes de tentar
+ carregar o fluxo para dentro desse repositório.</para>
</sect2>
More information about the svn-pt_br
mailing list