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

codesite-noreply at google.com codesite-noreply at google.com
Tue Dec 16 22:50:06 CST 2008


Author: mfandrade
Date: Tue Dec 16 18:12:38 2008
New Revision: 334

Modified:
    trunk/book/ch04-branching-and-merging.xml

Log:
Tradução do capítulo 4, "Fundir e Ramificar", subseção "Ciclo de Vida dos  
Dados",
concluindo a seção "Manutenção de Ramos".


Modified: trunk/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/book/ch04-branching-and-merging.xml	(original)
+++ trunk/book/ch04-branching-and-merging.xml	Tue Dec 16 18:12:38 2008
@@ -2191,16 +2191,16 @@

      <!-- ===============================================================  
-->
      <sect2 id="svn.branchmerge.maint.lifetime">
-      <title>Data Lifetimes</title>
+      <title>Ciclo de Vida dos Dados</title>

-      <para>Another nice feature of Subversion's model is that
-        branches and tags can have finite lifetimes, just like any
-        other versioned item.  For example, suppose you eventually
-        finish all your work on your personal branch of the
-        <filename>calc</filename> project.  After merging all of your
-        changes back into <filename>/calc/trunk</filename>, there's
-        no need for your private branch directory to stick around
-        anymore:</para>
+      <para>Outro bom recurso do modelo do Subversion é que os ramos e
+        rótulos podem ter ciclos de vida finitos, tal como qualquer
+        outro item versionado.  Por exemplo, suponha que você
+        eventualmente conclua todo o seu trabalho em seu ramo pessoal do
+        projeto <filename>calc</filename> project.  Depois de mesclar
+        todas as suas modificações de volta em
+        <filename>/calc/trunk</filename>, não é mais necessário manter o
+        diretório de seu ramo privado:</para>

        <screen>
  $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
@@ -2209,20 +2209,21 @@
  Committed revision 375.
  </screen>

-      <para>And now your branch is gone.  Of course it's not really
-        gone: the directory is simply missing from the
-        <literal>HEAD</literal> revision, no longer distracting
-        anyone.  If you use <command>svn checkout</command>,
-        <command>svn switch</command>, or <command>svn list</command>
-        to examine an earlier revision, you'll still be able to see
-        your old branch.</para>
-
-      <para>If browsing your deleted directory isn't enough, you can
-        always bring it back.  Resurrecting data is very easy in
-        Subversion.  If there's a deleted directory (or file) that
-        you'd like to bring back into <literal>HEAD</literal>, simply
-        use <command>svn copy -r</command> to copy it from the old
-        revision:</para>
+      <para>E agora seu ramo se foi.  É claro que ele não se foi
+        realmente: o diretório foi simplesmente removido da revisão
+        <literal>HEAD</literal> para não distrair mais ninguém.  Se você
+        executar <command>svn checkout</command>, <command>svn
+        switch</command>, ou <command>svn list</command> para verificar
+        uma revisão anterior, você ainda poderá ver seu antigo
+        ramo.</para>
+
+      <para>Se navegar em seu diretório excluído não for o bastante,
+        você sempre poderá trazê-lo de volta.  Ressuscitar dados é algo
+        muito fácil no Subversion.  Se houver um diretório (ou arquivo)
+        excluído que você gostaria de trazer de volta para a revisão
+        <literal>HEAD</literal>, simplesmente use <command>svn copy
+        -r</command> para copiá-lo a partir de sua revisão
+        antiga:</para>

        <screen>
  $ svn copy -r 374  
http://svn.example.com/repos/calc/branches/my-calc-branch \
@@ -2231,19 +2232,20 @@
  Committed revision 376.
  </screen>

-      <para>In our example, your personal branch had a relatively
-        short lifetime: you may have created it to fix a bug or
-        implement a new feature.  When your task is done, so is the
-        branch.  In software development, though, it's also common to
-        have two <quote>main</quote> branches running side-by-side for
-        very long periods.  For example, suppose it's time to release
-        a stable version of the <filename>calc</filename> project to the
-        public, and you know it's going to take a couple of months to
-        shake bugs out of the software.  You don't want people to add
-        new features to the project, but you don't want to tell all
-        developers to stop programming either.  So instead, you create
-        a <quote>stable</quote> branch of the software that won't
-        change much:</para>
+      <para>Em nosso exemplo, seu ramo pessoal tinha um ciclo de vida
+        relativamente curto: você pode tê-lo criado para corrigir um bug
+        ou implementar um novo recurso.  Quando sua tarefa estiver
+        terminada, então o ramo também estará.  No desenvolvimento de
+        software, porém, também é comum ter dois ramos
+        <quote>principais</quote> executando lado-a-lado por longos
+        períodos.  Por exemplo, suponha que seja o momento de lançar uma
+        versão estável do projeto <filename>calc</filename> para o
+        público, e você sabe que irá levar mais alguns meses para
+        remover todos os bugs do software.  Você não quer que as pessoas
+        adicionem novos recursos ao projeto, mas você também não quer
+        dizer para que todos os desenvolvedores parem de trabalhar.
+        Assim, você cria um ramo <quote>estável</quote> do software, o
+        qual você não irá modificar muito:</para>

        <screen>
  $ svn copy http://svn.example.com/repos/calc/trunk \
@@ -2253,16 +2255,18 @@
  Committed revision 377.
  </screen>

-      <para>And now developers are free to continue adding
-        cutting-edge (or experimental) features to
-        <filename>/calc/trunk</filename>, and you can declare a
-        project policy that only bug fixes are to be committed to
-        <filename>/calc/branches/stable-1.0</filename>.  That is, as
-        people continue to work on the trunk, a human selectively
-        ports bug fixes over to the stable branch.  Even after the
-        stable branch has shipped, you'll probably continue to
-        maintain the branch for a long time—that is, as long
-        as you continue to support that release for customers.</para>
+      <para>E agora os desenvolvedores estão livres para continuar
+        adicionando as novas funcionalidades planejadas (ou
+        experimentais) em <filename>/calc/trunk</filename>, e você pode
+        definir uma política de projeto que apenas correções de bugs
+        serão submetidas para
+        <filename>/calc/branches/stable-1.0</filename>.  Dessa forma,
+        como as pessoas continuam a trabalhar no tronco, uma pessoa
+        seleciona as correções de bugs a serem portadas para o ramo
+        estável.  Mesmo depois que o conteúdo do ramo estável tenha sido
+        distribuído, você provavelmente irá continuar mantendo o ramo
+        por um longo período—isto é, enquanto você continuar a dar
+        suporte àquele release de software para seus clientes.</para>

      </sect2>



More information about the svn-pt_br mailing list