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

codesite-noreply at google.com codesite-noreply at google.com
Tue Mar 18 23:20:23 CDT 2008


Author: blabos
Date: Tue Mar 18 21:19:44 2008
New Revision: 49

Modified:
   trunk/book/ch01-fundamental-concepts.xml

Log:
Revisions
How Working Copies Track the Repository
Mixed Revision Working Copies
Summary

Still in auto-revision

Modified: trunk/book/ch01-fundamental-concepts.xml
==============================================================================
--- trunk/book/ch01-fundamental-concepts.xml	(original)
+++ trunk/book/ch01-fundamental-concepts.xml	Tue Mar 18 21:19:44 2008
@@ -588,67 +588,67 @@
     
     <!-- =============================================================== -->
     <sect2 id="svn.basic.in-action.revs">
-      <title>Revisions</title>
+      <title>Revisões</title>
 
-      <para>An <command>svn commit</command> operation publishes
-        changes to any number of files and directories as a single
-        atomic transaction.  In your working copy, you can change
-        files' contents; create, delete, rename and copy files and
-        directories; then commit a complete set of changes as an
-        atomic transaction.</para>
-
-      <para>By <quote>atomic transaction</quote>, we mean simply this:
-        either all of the changes happen in the repository, or none of
-        them happen.  Subversion tries to retain this atomicity in the
-        face of program crashes, system crashes, network problems, and
-        other users' actions.</para>
-
-      <para>Each time the repository accepts a commit, this creates a
-        new state of the filesystem tree, called a
-        <firstterm>revision</firstterm>.  Each revision is assigned a
-        unique natural number, one greater than the number of the
-        previous revision.  The initial revision of a freshly created
-        repository is numbered zero, and consists of nothing but an
-        empty root directory.</para>
-
-      <para><xref linkend="svn.basic.in-action.revs.dia-1"/> illustrates a nice way to
-        visualize the repository.  Imagine an array of revision
-        numbers, starting at 0, stretching from left to right.  Each
-        revision number has a filesystem tree hanging below it, and
-        each tree is a <quote>snapshot</quote> of the way the
-        repository looked after a commit.</para>
+      <para>Uma operação <command>svn commit</command> publica as alterações
+        feitas em qualquer número de arquivos o diretórios como uma única
+        transação atômica. Em sua cópia de trabalho, você pode alterar o conteúdo
+        de arquivos; criar, deletar, renomear e copiar arquivos e diretórios;
+        e então comitar um conjunto completo de alterações em uma transação
+        atômica.</para>
+
+      <para>Por <quote>transação atômica</quote>, nos entendemos simplesmente
+	isto: Ou são efetivadas todas as alterações no repositório, ou nenhuma
+	delas. O Subversion tenta manter esta atomicidade em face de crashes
+	do programa ou do sistema, problemas de rede ou outras ações de
+	usuários.</para>
+
+      <para>Cada vez que o repositório aceita um commit, isto cria
+	um novo estado na árvore de arquivos, chamado
+	<firstterm>revisão</firstterm>. Cada revisão é assinalada
+	com um único número natural, incrementado de um em relação
+	à revisão anterior. A revisão inicial de um repositório recém
+	criado é numerada com zero, e consiste em nada além de um
+	diretório raiz vazio.</para>
+
+      <para>A figura <xref linkend="svn.basic.in-action.revs.dia-1"/> ilustra uma forma simples
+        para visualizar o repositório. Imagine um array de números de revisões, iniciando
+        em zero, alongando-se da esquerda para a direita. Cada número de revisão tem
+        uma árvore de arquivos pendurada abaixo dela, e cada árvore é um
+        <quote>snapshot</quote> da forma como o repositório podia ser visto após
+        um commit.</para>
 
       <figure id="svn.basic.in-action.revs.dia-1">
-        <title>The repository</title>
+        <title>O Repositório</title>
         <graphic fileref="images/ch02dia7.png"/>
       </figure>
 
       <sidebar>
-        <title>Global Revision Numbers</title>
+        <title>Números de Revisão Globais</title>
 
-        <para>Unlike most version control systems, Subversion's
-          revision numbers apply to <emphasis>entire trees</emphasis>,
-          not individual files.  Each revision number selects an
-          entire tree, a particular state of the repository after some
-          committed change.  Another way to think about it is that
-          revision N represents the state of the repository filesystem
-          after the Nth commit.  When Subversion users talk
-          about <quote>revision 5 of
-          <filename>foo.c</filename></quote>, they really mean
-          <quote><filename>foo.c</filename> as it appears in revision
-          5.</quote> Notice that in general, revisions N and M of a
-          file do <emphasis>not</emphasis> necessarily differ!  Many
-          other version control systems use per-file revision numbers,
-          so this concept may seem unusual at first. (Former CVS users
-          might want to see <xref linkend="svn.forcvs"/> for more
-          details.)</para>
+        <para>Ao contrários de outros sistemas de controle de versão,
+          os números de revisão do Subversion se aplicam à
+          <emphasis>árvore inteira</emphasis>, não a arquivos individuais.
+          Cada número de revisão refere-se a uma árvore inteira, um estado
+          particular do repositório após determinadas alterações serem comitadas.
+          Uma outra forma de pensar a respeito é imaginar que a revisão
+          N representa o estado do sistema de arquivos do repositório após o
+          N-ésimo commit. Quando os usuários do Subversion falam sobre a
+          <quote>revisão número 5 do arquivo <filename>foo.c</filename></quote>,
+          eles realmente entendem o <quote><filename>foo.c</filename> que aparece
+          na revisão 5.</quote> Note que em geral, revisões N e M de um arquivo
+          podem <emphasis>não</emphasis> ser necessariamente diferentes! Muitos
+          outros sistemas de controle de versão usam número de revisão por arquivo,
+          então este conceito pode parecer não usual à primeira vista. (Usuários
+          do CVS podem querer ver <xref linkend="svn.forcvs"/> para mais
+          detalhes.)</para>
       </sidebar>
 
-      <para>It's important to note that working copies do not always
-        correspond to any single revision in the repository; they may
-        contain files from several different revisions.  For example,
-        suppose you check out a working copy from a repository whose
-        most recent revision is 4:</para>
+      <para>É importante notar que nem sempre as cópias de trabalho
+        correspondem a uma única revisão do repositório; elas podem
+        conter arquivos de várias revisões diferentes. Por exemplo,
+        suponha que você faça checkout de uma cópia de trabalho cuja
+        revisão mais recente seja 4:</para>
 
       <screen>
 calc/Makefile:4
@@ -656,12 +656,12 @@
      button.c:4
 </screen>
 
-      <para>At the moment, this working directory corresponds exactly
-        to revision 4 in the repository.  However, suppose you make a
-        change to <filename>button.c</filename>, and commit that
-        change.  Assuming no other commits have taken place, your
-        commit will create revision 5 of the repository, and your
-        working copy will now look like this:</para>
+      <para>Neste momento, este diretório de trabalho corresponde exatamente
+        à revisão número 4 no repositório. Contudo, suponha que você faça uma
+        alteração no arquivo <filename>button.c</filename>, e publique essa
+        alteração. Assumindo que nenhum outro commit tenha sido feito, o seu
+        commit irá criar a revisão 5 no repositório, e sua cópia de trabalho
+        agora irá parecer com isto:</para>
 
       <screen>
 calc/Makefile:4
@@ -669,10 +669,10 @@
      button.c:5
 </screen>
 
-      <para>Suppose that, at this point, Sally commits a change to
-        <filename>integer.c</filename>, creating revision 6.  If you
-        use <command>svn update</command> to bring your working copy
-        up to date, then it will look like this:</para>
+      <para>Suponha que neste ponto, Sally publique uma alteração no arquivo
+        <filename>integer.c</filename>, crianado a revisão 6. Se você usar o
+        comando <command>svn update</command> para atualizar a sua cópia de
+        trabalho, então ela irá parecer com isto:</para>
 
       <screen>
 calc/Makefile:6
@@ -680,245 +680,244 @@
      button.c:6
 </screen>
 
-      <para>Sally's change to <filename>integer.c</filename> will
-        appear in your working copy, and your change will still be
-        present in <filename>button.c</filename>.  In this example,
-        the text of <filename>Makefile</filename> is identical in
-        revisions 4, 5, and 6, but Subversion will mark your working
-        copy of <filename>Makefile</filename> with revision 6 to
-        indicate that it is still current.  So, after you do a clean
-        update at the top of your working copy, it will generally
-        correspond to exactly one revision in the repository.</para>
+      <para>A alteração de Sally no arquivo <filename>integer.c</filename>
+        irá aparecer em sua cópia de trabalho, e a sua alteração no
+        arquivo <filename>button.c</filename> ainda estará presente. Neste
+        exemplo, o texto do arquivo <filename>Makefile</filename> é idêntico
+        nas revisões 4, 5, e 6, mas o Subversion irá marcar a sua cópia do
+        arquivo <filename>Makefile</filename> com a revisão 6 para indicar que
+        a mesma é a corrente. Então, depois de você fazer uma atualização
+        completa na sua cópia de trabalho, ela geralmente corresponderá
+        exatamente a uma revisão do repositório.</para>
 
     </sect2>
 
 
     <!-- =============================================================== -->
     <sect2 id="svn.basic.in-action.track-repos">
-      <title>How Working Copies Track the Repository</title>
+      <title>Como as Cópias de Trabalho Acompanham o Repositório</title>
 
-      <para>For each file in a working directory, Subversion records
-        two essential pieces of information in the
-        <filename>.svn/</filename> administrative area:</para>
+      <para>Para cada arquivo em um diretório de trabalho, o Subversion
+        registra duas peças de informações essenciais na área administrativa
+        <filename>.svn/</filename>:</para>
 
 
       <itemizedlist>
         <listitem>
-          <para>what revision your working file is based on (this is
-            called the file's <firstterm>working
-            revision</firstterm>), and</para>
+          <para>em qual revisão o seu arquivo local é baseado
+            (isto é chamado de <firstterm>revisão local</firstterm>
+            do arquivo), e</para>
         </listitem>
 
         <listitem>
-          <para>a timestamp recording when the local copy was last
-            updated by the repository.</para>
+          <para>a data e a hora da última vez que a cópia local foi atualizada
+            a partir do repositório.</para>
         </listitem>
       </itemizedlist>
 
-      <para>Given this information, by talking to the repository,
-        Subversion can tell which of the following four states a
-        working file is in:</para>
+      <para>Dadas estas inmformações, conversando com o repositório,
+        o Subversion pode dizer em qual dos seguintes quatro estados
+        um arquivo local está:</para>
 
       <variablelist>
         <varlistentry>
-          <term>Unchanged, and current</term> 
+          <term>Não-Modificado, e corrente</term> 
 
           <listitem>
-            <para>The file is unchanged in the working directory, and
-              no changes to that file have been committed to the
-              repository since its working revision.  An <command>svn
-              commit</command> of the file will do nothing, and an
-              <command>svn update</command> of the file will do
-              nothing.</para>
+            <para>O arquivo não foi modificado no diretório local,
+              e nenhuma alteração foi publicada no repositório
+              desde a revisão corrente. O comando <command>
+              svn commit</command> no arquivo não fará nada,
+              e um comando <command>svn update
+              </command> também não..</para>
           </listitem>
         </varlistentry>
 
         <varlistentry>
-          <term>Locally changed, and current</term>
+          <term>Localmente alterado, e corrente</term>
 
           <listitem>
-            <para>The file has been changed in the working directory,
-              and no changes to that file have been committed to the
-              repository since you last updated.  There are local
-              changes that have not been committed to the repository,
-              thus an <command>svn commit</command> of the file will
-              succeed in publishing your changes, and an <command>svn
-              update</command> of the file will do nothing.</para>
+            <para>O arquivo foi alterado no diretório local, mas
+              nenhuma alteração foi publicada no repositório desde
+              o último update. existem alterações locais que ainda
+              não foram publicadas no repositório, assim o comando
+              <command>svn commit</command> no arquivo resultará na
+              publicação dessas alterações, e um comando <command>svn
+              update</command> não fará nada.</para>
           </listitem>
         </varlistentry>
 
         <varlistentry>
-          <term>Unchanged, and out-of-date</term> 
+          <term>Não-Modificado, e desatualizado</term> 
 
           <listitem>
-            <para>The file has not been changed in the working
-              directory, but it has been changed in the repository.
-              The file should eventually be updated, to make it
-              current with the latest public revision.  An <command>svn
-              commit</command> of the file will do nothing, and an
-              <command>svn update</command> of the file will fold the
-              latest changes into your working copy.</para>
+            <para>O arquivo não foi alterado no diretório local,
+              mas foi alterado no repositório. O arquivo pode ser
+              eventualmente atualizado, para sincronizá-lo com a
+              última revisão pública. O comando <command>svn
+              commit</command> no arquivo não irá fazer nada, mas
+              o comando <command>svn update</command> irá trazer
+              as últimas alterações para a sua cópia local.</para>
           </listitem>
         </varlistentry>
 
         <varlistentry>
-          <term>Locally changed, and out-of-date</term>
+          <term>Localmente Modificado, e desatualizado</term>
 
           <listitem>
-            <para>The file has been changed both in the working
-              directory, and in the repository.  An <command>svn
-              commit</command> of the file will fail with an
-              <quote>out-of-date</quote> error.  The file should be
-              updated first; an <command>svn update</command> command
-              will attempt to merge the public changes with the local
-              changes.  If Subversion can't complete the merge in a
-              plausible way automatically, it leaves it to the user to
-              resolve the conflict.</para>
+            <para>O arquivo foi alterado tanto no diretório loca quanto
+              no repositório. O comando <command>svn commit</command>
+              no arquivo irá falhar com o erro <quote>out-of-date</quote>
+              (desatualizado). O arquivo deve ser atualizado primeiro; o
+              comando <command>svn update</command> vai tentar combinar
+              as alterações do repositório com as locais. Se o Subversion
+              não conseguir completar a combinação de uma forma plausível
+              automaticamente, ele deixará para o usuário resolver o
+              conflito.</para>
           </listitem>
         </varlistentry>
       </variablelist>
 
 
-      <para>This may sound like a lot to keep track of, but the
-        <command>svn status</command> command will show you the state
-        of any item in your working copy.  For more information on
-        that command, see
+      <para>Isto pode soar como muito para acompanhar, mas o comando
+        <command>svn status</command> mostrará para você o estado de
+        qualquer item em seu diretório local. Para maiores informações
+        sobre este comando, veja
         <xref linkend="svn.tour.cycle.examine.status" />.</para>
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.basic.in-action.mixedrevs">
-      <title>Mixed Revision Working Copies</title>
+      <title>Revisões Locais Mistas</title>
 
-      <para>As a general principle, Subversion tries to be as flexible
-        as possible.  One special kind of flexibility is the ability
-        to have a working copy containing files and directories with a
-        mix of different working revision numbers.  Unfortunately,
-        this flexibility tends to confuse a number of new users.  If
-        the earlier example showing mixed revisions perplexed you,
-        here's a primer on both why the feature exists and how to make
-        use of it.</para>
+      <para>Como um princípio geral, o subversion tenta ser tão flexível
+        quanto possível. Um tipo especial de flexibilidade é a capacidade
+        de ter uma cópia local contendo arquivos e diretórios com uma
+        mistura de diferentes revisões. Infelizmente esta flexibilidade
+        tende a confundir inúmeros novos usuários. Se o exemplo anterior
+        mostrando revisões mistas deixou você perplexo, aqui está um
+        exemplo mostrando tanto a razão pela qual o fucncionalidade
+        existe, quanto como fazer para usá-la.</para>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.basic.in-action.mixedrevs.update-commit">
-        <title>Updates and Commits are Separate</title>
+        <title>Updates e Commits são Separados</title>
 
-        <para>One of the fundamental rules of Subversion is that
-          a <quote>push</quote> action does not cause
-          a <quote>pull</quote>, nor the other way around.  Just
-          because you're ready to submit new changes to the repository
-          doesn't mean you're ready to receive changes from other
-          people.  And if you have new changes still in progress,
-          then <command>svn update</command> should gracefully merge
-          repository changes into your own, rather than forcing you to
-          publish them.</para>
-
-        <para>The main side-effect of this rule is that it means a
-          working copy has to do extra bookkeeping to track mixed
-          revisions, and be tolerant of the mixture as well.  It's
-          made more complicated by the fact that directories
-          themselves are versioned.</para>
-
-        <para>For example, suppose you have a working copy entirely at
-          revision 10.  You edit the
-          file <filename>foo.html</filename> and then perform
-          an <command>svn commit</command>, which creates revision 15
-          in the repository.  After the commit succeeds, many new
-          users would expect the working copy to be entirely at
-          revision 15, but that's not the case!  Any number of changes
-          might have happened in the repository between revisions 10
-          and 15.  The client knows nothing of those changes in the
-          repository, since you haven't yet run <command>svn
-          update</command>, and <command>svn commit</command> doesn't
-          pull down new changes.  If, on the other hand,
-          <command>svn commit</command> <emphasis>were</emphasis> to
-          automatically download the newest changes, then it would be
-          possible to set the entire working copy to revision
-          15—but then we'd be breaking the fundamental rule
-          of <quote>push</quote> and <quote>pull</quote> remaining
-          separate actions.  Therefore the only safe thing the
-          Subversion client can do is mark the one
-          file—<filename>foo.html</filename>—as being at
-          revision 15.  The rest of the working copy remains at
-          revision 10.  Only by running <command>svn update</command>
-          can the latest changes be downloaded, and the whole working
-          copy be marked as revision 15.</para>
+        <para>Uma das regras fundamentais do Subversion é
+          que uma ação de <quote>push</quote> não causa um
+          <quote>pull</quote>, e vice versa. Só porque você está
+          pronto para publicar novas alterações no repositório não
+          significa que você está pronto para receber as alterações
+          de outras pessoas. E se você tiver novas alterações em curso,
+          então o comando <command>svn update</command> deveria
+          graciosamente combinar as alterações no repositório com as
+          suas próprias, ao invés de forçar você a publicá-las.</para>
+
+        <para>O principal efeito colateral dessa regra significa que
+          uma cópia local tem que fazer uma escrituração extra para
+          acompanhar revisões mistas, bem como ser tolerante a misturas.
+          Isso fica mais complicado pelo fato de os diretórios também
+          serem versionados.</para>
+
+        <para>Por exemplo, suponha que você tenha uma cópia local
+          inteiramente na revisão 10. Você edita o arquivo
+          <filename>foo.html</filename> e então realiza um comando
+          <command>svn commit</command>, o qual cria a revisão 15
+          no repositório. Após o commit acontecer, muitos novos usuários
+          poderiam esperar que a cópia local estivesse na revisão 15,
+          mas este não é o caso! Qualquer número de alterações poderia
+          ter acontecido no repositório entre as revisões 10 e 15.
+          O cliente nada sabe sobre essas alterações no repositório,
+          pois você ainda não executou o comando <command>svn update
+          </command>, e o comando <command>svn commit</command> não
+          baixou as novas alterações no repositório. Se por outro lado,
+          o comando <command>svn commit</command> <emphasis>tivesse
+          </emphasis> feito o download das novas alterações automaticamente,
+          então seria possível que a cópia local inteira estivesse na revisão
+          15 - mas então nós teríamos quebrado a regra fundamental onde
+          <quote>push</quote> e <quote>pull</quote> permanecem como
+          ações separadas. Portanto a única coisa segura que o cliente
+          Subversion pode fazer é marcar o arquivo - <filename>foo.html
+          </filename> com a revisão 15. O restante da cópia local permanece
+          na revisão 10. Somente executando o comando <command>svn update
+          </command> as alterações mais recentes no repositório serão
+          baixadas, o a cópia local inteira será marcada com a revisão
+          15.</para>
 
       </sect3>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.basic.in-action.mixedrevs.normal">
-        <title>Mixed revisions are normal</title>
+        <title>Revisões misturadas são normais</title>
           
-        <para>The fact is, <emphasis>every time</emphasis> you run
-          <command>svn commit</command>, your working copy ends up
-          with some mixture of revisions.  The things you just
-          committed are marked as having larger working revisions than
-          everything else.  After several commits (with no updates
-          in-between) your working copy will contain a whole mixture
-          of revisions.  Even if you're the only person using the
-          repository, you will still see this phenomenon.  To examine
-          your mixture of working revisions, use the <command>svn
-          status --verbose</command> command (see <xref
-          linkend="svn.tour.cycle.examine.status"/> for more
-          information.)</para>
-
-        <para>Often, new users are completely unaware that their
-          working copy contains mixed revisions.  This can be
-          confusing, because many client commands are sensitive to the
-          working revision of the item they're examining.  For
-          example, the <command>svn log</command> command is used to
-          display the history of changes to a file or directory (see
-          <xref linkend="svn.tour.history.log"/>).  When the user
-          invokes this command on a working copy object, they expect
-          to see the entire history of the object.  But if the
-          object's working revision is quite old (often because
-          <command>svn update</command> hasn't been run in a long
-          time), then the history of the <emphasis>older</emphasis>
-          version of the object is shown.</para>
+        <para>O fato é, <emphasis>cada vez</emphasis> que você executar
+          um comando <command>svn commit</command>, sua cópia local
+          acabará tendo uma mistura de revisões. As coisas que você acabou
+          de publicar são marcadas com um número de revisão maior que todo
+          o resto. Após vários commits (sem updates entre eles) sua cópia
+          local irá conter uma completa mistura de revisões. Mesmo que você
+          seja a única pessoa utilizando o repositório, você ainda verá este
+          fenômeno. Para analisar a sua mistura de revisões use o comando
+          <command>svn status --verbose</command> (veja <xref
+          linkend="svn.tour.cycle.examine.status"/> para maiores
+          informações.)</para>
+
+        <para>Frequentemente, os novos usuários nem tomam consciência
+          de que suas cópias locais contêm revisões mistas. Isso pode
+          ser confuso, pois muitos comandos no cliente são sensíveis
+          às revisões que eles estão examinando. Por exemplo, o comando
+          <command>svn log</command> é usado para mostrar o histórico de
+          alterações em um arquivo ou diretório (veja <xref
+          linkend="svn.tour.history.log"/>). Quando o usuário invoca este
+          comando em um objeto da cópia local, ele espera ver o histórico
+          inteiro do objeto. Mas se a revisão local do objeto é muito
+          velha (muitas vezes porque o comando <command>svn update</command>
+          não foi executado por um longo tempo), então o histórico da
+          versão <emphasis>antiga</emphasis> do objeto é que será
+          mostrado.</para>
 
       </sect3>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.basic.in-action.mixedrevs.useful">
-        <title>Mixed revisions are useful</title>
+        <title>Revisões mistas são úteis</title>
 
-        <para>If your project is sufficiently complex, you'll discover
-          that it's sometimes nice to forcibly <firstterm>backdate</firstterm>
-          (or, update to a revision older than the one you already
-          have) portions of your working copy to an earlier revision; you'll
-          learn how to do that in <xref linkend="svn.tour"/>.  Perhaps
-          you'd like to test an earlier version of a sub-module
-          contained in a subdirectory, or perhaps you'd like to figure
-          out when a bug first came into existence in a specific file.
-          This is the <quote>time machine</quote> aspect of a version
-          control system—the feature which allows you to move
-          any portion of your working copy forward and backward in
-          history.</para>
+        <para>Se o seu projeto for suficientemente complexo, você irá
+          descobrir que algumas vezes é interessante forçar um <firstterm>
+          backdate</firstterm> (ou, atualizar para uma revisão mais antiga
+          que a que você tem) de partes de sua cópia local para revisões
+          anteriores; vocÇe irá aprender como fazer isso em <xref
+          linkend="svn.tour"/>. Talvez você queira testar uma versão anterior
+          de um sub-módulo contido em um subdiretório, ou talvez queira
+          descobrir quando um bug apareceu pela primeira vez eu arquivo
+          específico. Este é o aspecto de <quote>máquina do tempo</quote>
+          de um sitema de controle de versão - a funcionalidade que te permite
+          mover qualquer parte de sua cópia local para frente ou para trás
+          na história.</para>
 
       </sect3>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.basic.in-action.mixedrevs.limits">
-        <title>Mixed revisions have limitations</title>
+        <title>Revisões mistas têm limitações</title>
 
-        <para>However you make use of mixed revisions in your working
-          copy, there are limitations to this flexibility.</para>
+        <para>Apesar de você poder fazer uso de revisõesmistas em seu
+          ambiente local, esta flexibilidade tem limitações.</para>
           
-        <para>First, you cannot commit the deletion of a file or
-          directory which isn't fully up-to-date.  If a newer version
-          of the item exists in the repository, your attempt to delete
-          will be rejected, to prevent you from accidentally
-          destroying changes you've not yet seen.</para>
-
-        <para>Second, you cannot commit a metadata change to a
-          directory unless it's fully up-to-date.  You'll learn about
-          attaching <quote>properties</quote> to items in <xref
-          linkend="svn.advanced"/>.  A directory's working revision
-          defines a specific set of entries and properties, and thus
-          committing a property change to an out-of-date directory may
-          destroy properties you've not yet seen.</para>
+        <para>Primeiramente, você não pode publicar a deleção de um arquivo
+          ou diretório que não esteja completamente atualizado. Se uma
+          versão mais nova do item existe no repositório, sua tentativa de
+          deleção será rejeitada, para prevenir que você acidentalmente
+          destrua alterações que você ainda não viu.</para>
+
+        <para>Em segundo lugar, você não pode publicar alterações em meta-dados
+          de diretórios a menos que ele esteja completamente atualizado.
+          Você irá aprender a anexar <quote>propriedades</quote> aos itens
+          em <xref linkend="svn.advanced"/>. Uma revisão em um dretório local
+          define um conjunto específico de entradas e propriedades, e assim,
+          publicar alterações em propriedades de um diretório desatualizado
+          pode destruie propriedades que você ainda não viu.</para>
 
       </sect3>
 
@@ -930,36 +929,36 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.basic.summary">
-    <title>Summary</title>
+    <title>Sumário</title>
     
-    <para>We've covered a number of fundamental Subversion concepts in
-      this chapter:</para>
+    <para>Nós abordamos uma série de conceitos fundamentais do
+      Subversion neste capítulo:</para>
 
     <itemizedlist>
       <listitem>
-        <para>We've introduced the notions of the central repository,
-          the client working copy, and the array of repository
-          revision trees.</para>
+        <para>Nós introduzimos as noções de repositório central,
+          cópia local do cliente, e o array de árvores de revisões.</para>
       </listitem>
 
       <listitem>
-        <para>We've seen some simple examples of how two collaborators
-          can use Subversion to publish and receive changes from one
-          another, using the <quote>copy-modify-merge</quote>
-          model.</para>
+        <para>Vimos alguns exemplos simples de como dois colaboradores
+          podem utilizar o Subversion para publicar e receber as
+          alterações um do outro, utilizando o modelo <quote>
+          copy-modify-merge</quote>.</para>
       </listitem>
 
       <listitem>
-        <para>We've talked a bit about the way Subversion tracks and
-          manages information in a working copy.</para>
+        <para>Nós falamos um pouco sobre a maneira como o Subversion
+          acompanha e gerencia as informações de uma cópia local
+          do repositório.</para>
       </listitem>
 
     </itemizedlist>
 
-    <para>At this point, you should have a good idea of how Subversion
-      works in the most general sense.  Armed with this knowledge, you
-      should now be ready to move into the next chapter, which is a
-      detailed tour of Subversion's commands and features.</para>
+    <para>Neste ponto, você deve ter uma boa idéia de como o Subversion
+      funciona no sentido mais geral. Com este conhecimento, você já
+      deve estar pronto para avançar para o próximo capítulo, que é um
+      relato detalhado dos comandos e recursos do Subversion.</para>
 
   </sect1>
 




More information about the svn-pt_br mailing list