[svnbook-pt-br commit] r249 - trunk/book

codesite-noreply at google.com codesite-noreply at google.com
Mon Nov 17 22:59:13 CST 2008


Author: mfandrade
Date: Mon Nov 17 20:58:49 2008
New Revision: 249

Modified:
    trunk/book/ch03-advanced-topics.xml

Log:
Prossegue com a tradução do capítulo 3, "Tópicos Avançados", trecho
da seção "Revisões Marcadoras e Revisões Operativas" até a linha 2887.

Modified: trunk/book/ch03-advanced-topics.xml
==============================================================================
--- trunk/book/ch03-advanced-topics.xml	(original)
+++ trunk/book/ch03-advanced-topics.xml	Mon Nov 17 20:58:49 2008
@@ -2615,7 +2615,7 @@
    <!-- =================================================================  
-->
    <!-- =================================================================  
-->
    <sect1 id="svn.advanced.pegrevs">
-    <title>Revisões Peg e Revisões Operativas</title>
+    <title>Revisões Marcadoras e Revisões Operativas</title>

      <para>Nós copiamos, movemos, renomeamos, e substituímos
        completamente arquivos e diretórios em nossos computadores a todo
@@ -2696,39 +2696,39 @@
        rua.  Nosso motorista—e o nosso Subversion—precisa de um
        pouco mais de detalhes para poder fazer a coisa certa.</para>

-    <para>Na versão 1.1, i Subversion introduziu uma maneira para você  
dizer
+    <para>Na versão 1.1, o Subversion introduziu uma maneira para você  
dizer
        exatamente à que Main Street você se refere.  É chamada de
-      <firstterm>revisão peg</firstterm>, e é uma revisão disponibilizada  
pelo
+      <firstterm>revisão marcadora</firstterm>, e é uma revisão  
disponibilizada pelo
        Subversion apenas com propósito de identificar uma linha única de
        histórico.  Como no máximo um objeto versionado pode ocupar um  
caminho em
        um dado instante—ou, mais precisamente, em uma dada  
revisão—a
-      combinação de um caminho e uma revisão peg é tudo o que é necessário  
para
-      se referenciar a uma linha específica de histórico.  Revisões peg são
-      especificadas pelo cliente de linha de comando do Subversion usando
-      <firstterm>sintaxe de arroba</firstterm><footnote>N.T.: Em inglês, o
-      símbolo de arroba é lido como <quote>at</quote>, que tem o sentido de
-      <emphasis>em</emphasis> ou <emphasis>naquele
+      combinação de um caminho e uma revisão marcadora é tudo o que é
+      necessário para se referenciar a uma linha específica de histórico.
+      Revisões marcadoras são especificadas pelo cliente de linha de  
comando do
+      Subversion usando <firstterm>sintaxe de  
arroba</firstterm><footnote>N.T.:
+      Em inglês, o símbolo de arroba é lido como <quote>at</quote>, que  
tem o
+      sentido de <emphasis>em</emphasis> ou <emphasis>naquele
        lugar</emphasis>.</footnote>, assim chamada porque envolve anexar-se  
um
-      <quote>sinal de arroba</quote> (<literal>@</literal>) e a revisão  
peg ao
-      final do caminho com o qual a revisão está associada.</para>
+      <quote>sinal de arroba</quote> (<literal>@</literal>) e a revisão
+      marcadora ao final do caminho com o qual a revisão está  
associada.</para>

      <para>Mas e sobre as revisões dadas por <option>--revision  
(-r)</option>,
        as quais falamos tanto neste livro?  Essas revisões (ou conjuntos de
        revisões) são chamadas de <firstterm>revisões operativas</firstterm>  
(ou
        <firstterm>intervalos de revisões operativas</firstterm>).  Uma vez  
qua
        uma linha em particular do histórico tenha sido identificada  
usando-se um
-      caminho e uma revisão peg, o Subversion executa a operação  
requisitada
-      usando a(s) revisão(ões) operativa(s).  Para relacionar isto com  
nossa
-      analogia às ruas de Chicago, se nos disserem para irmos para até a  
Main
-      Street em Wheaton 606 N.,
+      caminho e uma revisão marcadora, o Subversion executa a operação
+      requisitada usando a(s) revisão(ões) operativa(s).  Para relacionar  
isto
+      com nossa analogia às ruas de Chicago, se nos disserem para irmos  
para
+      até a Main Street em Wheaton 606 N.,
        <footnote>
          <para>Main Street, Wheaton, 606 N., Illinois, é o endereço do  
Wheaton
            History Center.  Sacou—<quote>History
            Center</quote>?  Parece apropriado….</para>
        </footnote>
        poderíamos pensar na <quote>Main Street</quote> como nosso caminho e  
em
-      <quote>Wheaton</quote> como nossa revisão peg.  Estes dois pedaçoes  
de
-      informaçao identificam um único caminho que pode ser percorrido (em
+      <quote>Wheaton</quote> como nossa revisão marcadora.  Estes dois  
pedaçoes
+      de informaçao identificam um único caminho que pode ser percorrido  
(em
        sentido sul ou sentido norte na Main Street), e que nos permitir  
andar
        para cima e para baixo na Main Street ao acaso na busca pelo nosso
        destino.  Agora temos <quote>606 N.</quote> como nossa revisão  
operativa,
@@ -2736,156 +2736,155 @@
        ir.</para>

      <sidebar>
-      <title>The peg revision algorithm</title>
+      <title>O algoritmo de revisões marcadoras</title>

-      <para>The Subversion command-line performs the peg revision
-        algorithm any time it needs to resolve possible ambiguities in
-        the paths and revisions provided to it.  Here's an example of
-        such an invocation:</para>
+      <para>O Subversion em linha de comando executa o algoritmo de  
revisões
+        marcadora a qualquer momento em que precise resolver possíveis
+        ambiguidades nos caminhos e revisões por ele providos.  Aqui está  
um
+        exemplo de execução:</para>

        <screen>
  $ svn <replaceable>command</replaceable> -r  
<replaceable>OPERATIVE-REV</replaceable>  
item@<replaceable>PEG-REV</replaceable>
  </screen>

-      <para>If <replaceable>OPERATIVE-REV</replaceable> is older than
-        <replaceable>PEG-REV</replaceable>, then the algorithm is as
-        follows:</para>
+      <para>Se <replaceable>OPERATIVE-REV</replaceable> for mais antiga que
+        <replaceable>PEG-REV</replaceable>, então o algoritmo será o
+        seguinte:</para>

        <itemizedlist>

          <listitem>
-          <para>Locate <replaceable>item</replaceable> in the revision
-            identified by <replaceable>PEG-REV</replaceable>.  There
-            can be only one such object.</para>
+          <para>Localize o <replaceable>item</replaceable> na revisão
+            identificada por <replaceable>PEG-REV</replaceable>.  Deve ser
+            encontrado apenas um único objeto.</para>
          </listitem>

          <listitem>
-          <para>Trace the object's history backwards (through any
-            possible renames) to its ancestor in the revision
+          <para>Trace o histórico pregresso do objeto (através de eventuais
+            renomeações ocorridas) até seu ancestral na revisão
              <replaceable>OPERATIVE-REV</replaceable>.</para>
          </listitem>

          <listitem>
-          <para>Perform the requested action on that ancestor,
-            wherever it is located, or whatever its name might
-            be or have been at that time.</para>
+          <para>Execute a ação requisitada naquele ancestral, onde quer  
que ele
+            se encontre, ou qualquer que seja o nome que ele tenha ou que  
tenha
+            tido ao longo do tempo.</para>
          </listitem>

        </itemizedlist>

-      <para>But what if <replaceable>OPERATIVE-REV</replaceable> is
-        <emphasis>younger</emphasis> than
-        <replaceable>PEG-REV</replaceable>?  Well, that adds some
-        complexity to the theoretical problem of locating the path in
-        <replaceable>OPERATIVE-REV</replaceable>, because the path's
-        history could have forked multiple times (thanks to copy
-        operations) between <replaceable>PEG-REV</replaceable> and
-        <replaceable>OPERATIVE-REV</replaceable>.  And that's not
-        all—Subversion doesn't store enough information to
-        performantly trace an object's history forward, anyway.  So
-        the algorithm is a little different:</para>
+      <para>Mas e se <replaceable>OPERATIVE-REV</replaceable> for
+        <emphasis>mais recente</emphasis> que
+        <replaceable>PEG-REV</replaceable>?  Bem, isso adiciona alguma
+        complexidade ao problema teórico de localização do caminho em
+        <replaceable>OPERATIVE-REV</replaceable>, pois o histórico do  
caminho
+        pode ter sido ramificado várias vezes (graças a operações de cópia)
+        entre <replaceable>PEG-REV</replaceable> e
+        <replaceable>OPERATIVE-REV</replaceable>.  E isso não é  
tudo—de
+        qualquer maneira, o Subversion não armazena informação o suficiente
+        para traçar eficientemente o histórico das revisões à frente para  
um
+        objeto.  Assim, o algoritmo neste caso é um pouco diferente:</para>

        <itemizedlist>

          <listitem>
-          <para>Locate <replaceable>item</replaceable> in the revision
-            identified by <replaceable>OPERATIVE-REV</replaceable>.  There
-            can be only one such object.</para>
+          <para>Localize o <replaceable>item</replaceable> na revisão
+            identificada por <replaceable>OPERATIVE-REV</replaceable>.   
Deve
+            ser encontrado apenas um único objeto.</para>
          </listitem>

          <listitem>
-          <para>Trace the object's history backwards (through any
-            possible renames) to its ancestor in the revision
+          <para>Trace o histórico pregresso do objeto (através de eventuais
+            renomeações ocorridas) até seu ancestral na revisão
              <replaceable>PEG-REV</replaceable>.</para>
          </listitem>

          <listitem>
-          <para>Verify that the object's location (path-wise) in
-            <replaceable>PEG-REV</replaceable> is the same as it is in
-            <replaceable>OPERATIVE-REV</replaceable>.  If that's the
-            case, then at least the two locations are known to be
-            directly related, so perform the requested action on the
-            location in <replaceable>OPERATIVE-REV</replaceable>.
-            Otherwise, relatedness was not established, so error out
-            with a loud complaint that no viable location was found.
-            (Someday, we expect that Subversion will be able to handle
-            this usage scenario with more flexibility and
-            grace.)</para>
+          <para>Verifique se a localização do objeto (caminho) em
+              <replaceable>PEG-REV</replaceable> é a mesma que o era na  
revisão
+            <replaceable>OPERATIVE-REV</replaceable>.  Se for este o caso,
+            então sabe-se que pelo menos dois locais estão diretamente
+            relacionados, e então execute a ação requisitada na  
localização em
+            <replaceable>OPERATIVE-REV</replaceable>.  Caso contrário,  
nenhuma
+            relação pôde ser estabelecida, então exiba uma mensagem de erro
+            detalhando que nenhuma localização viável foi encontrada.   
(Algum
+            dia esperamos que o Subversion será capaz de lidar com este  
cenário
+            de uso com mais graça e flexibilidade.)</para>
          </listitem>

        </itemizedlist>

-      <para>Note that even when you don't explicitly supply a peg
-        revision or operative revision, they are still present.  For
-        your convenience, the default peg revision is
-        <literal>BASE</literal> for working copy items and
-        <literal>HEAD</literal> for repository URLs.  And when no
-        operative revision is provided, it defaults to being the same
-        revision as the peg revision.</para>
+      <para>Note que mesmo quando você não informa uma revisão marcadora  
ou uma
+        revisão operativa, elas ainda estarão presentes.  Para sua
+        conveniência, <literal>BASE</literal> é tida como revisão marcadora
+        padrão para itens em sua cópia de trabalho e  
<literal>HEAD</literal> o
+        é para URLs do repositório.  E quando nenhuma revisão operativa for
+        informada, por padrão será usada a mesma que a da revisão  
marcadora.</para>

      </sidebar>

-    <para>Say that long ago we created our repository, and in revision 1
-      added our first <filename>concept</filename> directory, plus an
-      <filename>IDEA</filename> file in that directory talking about
-      the concept.  After several revisions in which real code was
-      added and tweaked, we, in revision 20, renamed this directory to
-      <filename>frabnaggilywort</filename>.  By revision 27, we had a
-      new concept, a new <filename>concept</filename> directory to
-      hold it, and a new <filename>IDEA</filename> file to describe
-      it.  And then five years and twenty thousand revisions flew by,
-      just like they would in any good romance story.</para>
-
-    <para>Now, years later, we wonder what the
-      <filename>IDEA</filename> file looked like back in revision 1.
-      But Subversion needs to know if we are asking about how the
-      <emphasis>current</emphasis> file looked back in revision 1, or
-      if we are asking for the contents of whatever file lived at
-      <filename>concepts/IDEA</filename> in revision 1.  Certainly
-      those questions have different answers, and because of peg
-      revisions, you can ask either of them.  To find out how the
-      current <filename>IDEA</filename> file looked in that old
-      revision, you run:</para>
+    <para>Digamos que tenhamos criado nosso repositório muito tempo atrás,  
e
+      que na revisão 1 adicionamos nosso primeiro diretório
+      <filename>concept</filename>, além de um arquivo
+      <filename>IDEA</filename> nesse diretório contendo as idéias  
relacionadas
+      ao conceito.  Depois de algumas revisões nas quais códigos reais  
foram
+      adicionados e manipulados, nós, na revisão 20, renomeamos este  
diretório
+      para <filename>frabnaggilywort</filename>.  Lá pela revisão 27,  
temos um
+      novo conceito, e criamos um novo diretório  
<filename>concept</filename>
+      para armazená-lo, e um novo arquivo <filename>IDEA</filename> para
+      descrevê-lo.  E assim, cinco anos e vinte mil revisões se passaram,  
tal
+      como seria em qualquer história de romance que se preze.</para>
+
+    <para>Agora, anos depois, nos questionamos como seria ter de volta o
+      arquivo <filename>IDEA</filename> tal como na revisão 1.  Mas o
+      Subversion precisa saber se nós estamos querendo saber sobre como o
+      <emphasis>atual</emphasis> arquivo se pareceria na revisão 1, ou se
+      estamos solicitando o conteúdo de qualquer que fosse o arquivo que
+      estivava como <filename>concepts/IDEA</filename> na revisão 1.
+      Certamente estas questões têm respostas diferentes, e devido as  
revisões
+      marcadoras, é possível obter ambas as respostas.  Para ver como o  
arquivo
+      <filename>IDEA</filename> atual era naquela revisão antiga, você
+      executa:</para>

      <screen>
  $ svn cat -r 1 concept/IDEA
  svn: Unable to find repository location for 'concept/IDEA' in revision 1
  </screen>

-    <para>Of course, in this example, the current
-      <filename>IDEA</filename> file didn't exist yet in revision 1,
-      so Subversion gives an error.  The command above is shorthand
-      for a longer notation which explicitly lists a peg revision.
-      The expanded notation is:</para>
+    <para>É claro, neste exemplo, o atual arquivo  
<filename>IDEA</filename> não
+      existia ainda na revisão 1, então o Subversion lhe exibe um erro.  O
+      comando acima é uma versão resumida para uma notação mais longa que
+      relaciona explicitamente uma revisão marcadora.  A notação expandida
+      é:</para>

      <screen>
  $ svn cat -r 1 concept/IDEA at BASE
  svn: Unable to find repository location for 'concept/IDEA' in revision 1
  </screen>

-    <para>And when executed, it has the expected results.</para>
+    <para>E quando executada, ela dá os mesmos resultados esperados.</para>

-    <para>The perceptive reader is probably wondering at this point if
-      the peg revision syntax causes problems for working copy paths
-      or URLs that actually have at signs in them.  After
-      all, how does <command>svn</command> know whether
-      <literal>news at 11</literal> is the name of a directory in my
-      tree, or just a syntax for <quote>revision 11 of
-      <filename>news</filename></quote>?  Thankfully, while
-      <command>svn</command> will always assume the latter, there is a
-      trivial workaround.  You need only append an at sign to the
-      end of the path, such as <literal>news at 11@</literal>.
-      <command>svn</command> only cares about the last at sign in
-      the argument, and it is not considered illegal to omit a literal
-      peg revision specifier after that at sign.  This workaround
-      even applies to paths that end in an at sign—you would
-      use <literal>filename@@</literal> to talk about a file named
+    <para>Neste ponto, provavelmente o leitor mais atento está se  
perguntando
+      se a sintaxe de revisões marcadoras causa problemas em caminhos na  
c[opia
+      de trabalho ou em URLs que atualmente tenham sinais em si mesmas.   
Depois
+      de tudo, como o <command>svn</command> sabe se
+      <literal>news at 11</literal> é o nome de um diretório em minha árvore,  
ou
+      se é apenas uma sintaxe para a <quote>revisão 11 de
+      <filename>news</filename></quote>?  Felizmente, ainda que o
+      <command>svn</command> considere sempre esta última opção, existe uma
+      regra trivial.  Você só precisa adicionar um sinal de arroba ao  
final do
+      caminho, como em <literal>news at 11@</literal>.  O  
<command>svn</command>
+      só irá se importar com o último sinal de arroba no argumento, e que  
não
+      seja considerado ilegal omitir um especificador do número da revisão
+      marcadora depois desse arroba.  Esta regra também se aplica a  
caminhos
+      que terminal com um sinal de arroba—você poderia usar
+      <literal>filename@@</literal> para se referir a um arquivo chamado
        <filename>filename@</filename>.</para>

-    <para>Let's ask the other question, then—in revision 1, what
-      were the contents of whatever file occupied the address
-      <filename>concepts/IDEA</filename> at the time?  We'll use an
-      explicit peg revision to help us out.</para>
+    <para>Vamos considerar a outra questão, então—na revisão 1, como  
era
+      estava o conteúdo de qualquer que seja o arquivo que estava ocupando  
o
+      endereço <filename>concepts/IDEA</filename> naquele momento?  Vamos  
usar
+      explicitamente uma revisão marcadora para nos ajudar.</para>

      <screen>
  $ svn cat concept/IDEA at 1


More information about the svn-pt_br mailing list