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

codesite-noreply at google.com codesite-noreply at google.com
Fri Nov 28 20:24:09 CST 2008


Author: mfandrade
Date: Fri Nov 28 18:23:42 2008
New Revision: 314

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

Log:
Tradução do capítulo "Fundir e Ramificar",
seção "Padrões Comuns de Ramificação",
sub-subseções "Ramos para Distribuição (Releases)" e "Ramos de Novos  
Recursos (Features)".


Modified: trunk/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/book/ch04-branching-and-merging.xml	(original)
+++ trunk/book/ch04-branching-and-merging.xml	Fri Nov 28 18:23:42 2008
@@ -1572,181 +1572,198 @@

      <!-- ===============================================================  
-->
      <sect2 id="svn.branchmerge.commonuses.patterns">
-      <title>Common Branching Patterns</title>
+      <title>Padrões de Ramificação Comuns</title>

-      <para>Version control is most often used for software
-        development, so here's a quick peek at two of the most common
-        branching/merging patterns used by teams of programmers.  If
-        you're not using Subversion for software development, feel
-        free to skip this section.  If you're a software developer
-        using version control for the first time, pay close attention,
-        as these patterns are often considered best practices by
-        experienced folk.  These processes aren't specific to
-        Subversion; they're applicable to any version control system.
-        Still, it may help to see them described in Subversion
-        terms.</para>
+      <para>Controle de versão é muito usado para desenvolvimento de
+        software, então aqui está uma rápida mostra de dois dos padrões
+        mais comuns de ramificação/fusão usados por equipes de
+        programadores.  Se você não estiver usando o Subversion para
+        desenvolvimento de software, fique à vontade para pular esta
+        seção.  Mas se você for um desenvolvedor de software usando
+        controle de versão pela primeira vez, preste bastante atenção,
+        já que estes padrões são frequentemente considerados como
+        melhores práticas por pessoas mais experientes.  Estes
+        procedimentos não são específicos para o Subversion; sendo
+        aplicáveis a qualquer sistema de controle de versão.  Além do
+        que pode ajudar ver tais padrões aplicados ao ambiente do
+        Subversion.</para>

        <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
-->
        <sect3 id="svn.branchmerge.commonuses.patterns.release">
-        <title>Release Branches</title>
+        <title>Ramos para Distribuição  
(<foreignphrase>Releases</foreignphrase>)</title>

-        <para>Most software has a typical lifecycle: code, test,
-          release, repeat.  There are two problems with this process.
-          First, developers need to keep writing new features while
-          quality-assurance teams take time to test supposedly-stable
-          versions of the software.  New work cannot halt while the
-          software is tested.  Second, the team almost always needs to
-          support older, released versions of software; if a bug is
-          discovered in the latest code, it most likely exists in
-          released versions as well, and customers will want to get
-          that bugfix without having to wait for a major new
-          release.</para>
+        <para>A maioria dos softwares possuem um ciclo de vida típico:
+          codifique, teste, entregue, repita.  Há dois problemas com
+          este processo.  Primeiro, os desenvolvedores precisam
+          continuar implementando novos recursos enquanto as equipes de
+          garantia da qualidade se dedicam a testar as versões
+          supostamente estáveis do software.  Segundo, a equipe quase
+          sempre precisa dar suporte a versões mais antigas, já
+          entregues, do software; se um bug for descoberto no código
+          mais recente, ele provavelmente também está presente nas
+          outras versões já distribuídas, e os clientes vão querer
+          obter a correção sem ter que esperar pelo lançamento de uma
+          próxima versão.</para>

-        <para>Here's where version control can help.  The typical
-          procedure looks like this:</para>
+        <para>É aqui que o controle de versão pode ajudar.  O
+          procedimento típico se parece com isto:</para>

        <itemizedlist>

          <listitem>
-          <para><emphasis>Developers commit all new work to the
-                trunk.</emphasis>
+          <para><emphasis>Desenvolvedores submetem todo o novo código
+              produzido para o tronco.</emphasis>

-              Day-to-day changes are committed to
-              <filename>/trunk</filename>: new features, bugfixes, and
-              so on.</para>
+              As modificações do dia-a-dia são submetidas para
+              <filename>/trunk</filename>: novos recursos, correções de
+              bugs, e por aí adiante.</para>
          </listitem>

          <listitem>
-          <para><emphasis>The trunk is copied to a
-                <quote>release</quote> branch.</emphasis>
-
-              When the team thinks the software is ready for release
-              (say, a 1.0 release), then <filename>/trunk</filename>
-              might be copied to
+          <para><emphasis>O tronco é copiado para um ramo de
+              <quote>release</quote>.</emphasis>
+
+              Quando a equipe achar que o software está pronto para o
+              lançamento de um novo release (digamos, uma versão 1.0),
+              então o <filename>/trunk</filename> pode ser copiado para
                <filename>/branches/1.0</filename>.</para>
          </listitem>

          <listitem>
-          <para><emphasis>Teams continue to work in parallel.</emphasis>
-
-              One team begins rigorous testing of the release branch,
-              while another team continues new work (say, for version
-              2.0) on <filename>/trunk</filename>.  If bugs are
-              discovered in either location, fixes are ported back and
-              forth as necessary.  At some point, however, even that
-              process stops.  The branch is <quote>frozen</quote> for
-              final testing right before a release.</para>
+          <para><emphasis>As equipes continuam a trabalhar em
+              paralelo.</emphasis>
+
+              Uma equipe começa uma rigorosa etapa de testes no ramo do
+              release, enquanto outra equipe continua prosseguindo com o
+              trabalho (digamos, para uma futura versão 2.0) em
+              <filename>/trunk</filename>.  Se bugs forem descobertos em
+              algum local, correções são portadas adequadamente conforme
+              o necessário.  Em algum ponto, porém, mesmo esse processo
+              pára.  O ramo é então <quote>congelado</quote> para testes
+              finais imediatamente antes do lançamento do
+              release.</para>
          </listitem>

          <listitem>
-          <para><emphasis>The branch is tagged and released.</emphasis>
+          <para><emphasis>O ramo é rotulado e distribuído.</emphasis>

-              When testing is complete,
-              <filename>/branches/1.0</filename> is copied to
-              <filename>/tags/1.0.0</filename> as a reference
-              snapshot.  The tag is packaged and released to
-              customers.</para>
+              Quando os testes tiverem terminado, o conteúdo de
+              <filename>/branches/1.0</filename> é copiado para
+              <filename>/tags/1.0.0</filename> como um registro
+              instantâneo de referência.  O rótulo é empacotado e
+              distribuído para os clientes.</para>
          </listitem>

          <listitem>
-          <para><emphasis>The branch is maintained over time.</emphasis>
+          <para><emphasis>O ramo é mantido ao longo do tempo.</emphasis>

-              While work continues on <filename>/trunk</filename> for
-              version 2.0, bugfixes continue to be ported from
-              <filename>/trunk</filename> to
-              <filename>/branches/1.0</filename>.  When enough
-              bugfixes have accumulated, management may decide to do a
-              1.0.1 release: <filename>/branches/1.0</filename> is
-              copied to <filename>/tags/1.0.1</filename>, and the tag
-              is packaged and released.</para>
+              Como o trabalho continua em <filename>/trunk</filename>
+              para uma versão 2.0, as correções de bugs continuam a ser
+              portadas de <filename>/trunk</filename> para
+              <filename>/branches/1.0</filename>.  Quando uma suficiente
+              quantidade de correções estiverem acumuladas, os gestores
+              do software pode decidir fazer uma versão 1.0.1:
+              <filename>/branches/1.0</filename> é copiado para
+              <filename>/tags/1.0.1</filename>, e o rótulo é empacotado
+              e distribuído.</para>
          </listitem>

          </itemizedlist>

-        <para>This entire process repeats as the software matures:
-          when the 2.0 work is complete, a new 2.0 release branch is
-          created, tested, tagged, and eventually released.  After
-          some years, the repository ends up with a number of release
-          branches in <quote>maintenance</quote> mode, and a number
-          of tags representing final shipped versions.</para>
+        <para>Este processo inteiro se repete enquanto o software
+          amadurece: quando a versão 2.0 estiver pronta, um novo ramo
+          para o release 2.0 é criado, testado, rotulado e eventualmente
+          distribuído.  Depois de alguns anos, o repositório acaba com
+          uma porção de ramos distribuídos em modo de
+          <quote>manutenção</quote>, e um conjunto de tags representando
+          as últimas versões entregues do software.</para>

        </sect3>

        <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
-->
        <sect3 id="svn.branchmerge.commonuses.patterns.feature">
-        <title>Feature Branches</title>
+        <title>Ramos de Novos Recursos  
(<foreignphrase>Features</foreignphrase>)</title>

-        <para>A <firstterm>feature branch</firstterm> is the sort of
-          branch that's been the dominant example in this chapter, the
-          one you've been working on while Sally continues to work on
-          <filename>/trunk</filename>.  It's a temporary branch
-          created to work on a complex change without interfering with
-          the stability of <filename>/trunk</filename>.  Unlike
-          release branches (which may need to be supported forever),
-          feature branches are born, used for a while, merged back to
-          the trunk, then ultimately deleted.  They have a finite span
-          of usefulness.</para>
-
-        <para>Again, project policies vary widely concerning exactly
-          when it's appropriate to create a feature branch.  Some
-          projects never use feature branches at all: commits to
-          <filename>/trunk</filename> are a free-for-all.  The
-          advantage to this system is that it's simple—nobody
-          needs to learn about branching or merging.  The disadvantage
-          is that the trunk code is often unstable or unusable.  Other
-          projects use branches to an extreme: no change is
-          <emphasis>ever</emphasis> committed to the trunk directly.
-          Even the most trivial changes are created on a short-lived
-          branch, carefully reviewed and merged to the trunk.  Then
-          the branch is deleted.  This system guarantees an
-          exceptionally stable and usable trunk at all times, but at
-          the cost of tremendous process overhead.</para>
-
-        <para>Most projects take a middle-of-the-road approach.  They
-          commonly insist that <filename>/trunk</filename> compile and
-          pass regression tests at all times.  A feature branch is
-          only required when a change requires a large number of
-          destabilizing commits.  A good rule of thumb is to ask this
-          question: if the developer worked for days in isolation and
-          then committed the large change all at once (so that
-          <filename>/trunk</filename> were never destabilized), would
-          it be too large a change to review?  If the answer to that
-          question is <quote>yes</quote>, then the change should be
-          developed on a feature branch.  As the developer commits
-          incremental changes to the branch, they can be easily
-          reviewed by peers.</para>
-
-        <para>Finally, there's the issue of how to best keep a feature
-          branch in <quote>sync</quote> with the trunk as work
-          progresses.  As we mentioned earlier, there's a great risk
-          to working on a branch for weeks or months; trunk changes
-          may continue to pour in, to the point where the two lines of
-          development differ so greatly that it may become a nightmare
-          trying to merge the branch back to the trunk.</para>
-
-        <para>This situation is best avoided by regularly merging
-          trunk changes to the branch.  Make up a policy: once a week,
-          merge the last week's worth of trunk changes to the branch.
-          Take care when doing this; the merging needs to be
-          hand-tracked to avoid the problem of repeated merges (as
-          described in
+        <para>Um <firstterm>ramo de novos recursos</firstterm> é o tipo
+          de ramo que tem sido o exemplo dominante neste capítulo,
+          aquele no qual você trabalhava enquanto Sally continuava seu
+          trabalho em <filename>/trunk</filename>.  É um ramo temporário
+          criado para lidar com uma modificação complexa sem interferir
+          na estabilidade de <filename>/trunk</filename>.
+          Diferentemente dos ramos de distribuição (os quais podem
+          continuar sendo mantidos para sempre), ramos de novos recursos
+          são criados, usados por um tempo, mesclados de volta ao
+          tronco, e finalmente excluídos.  Eles têm um escopo finito de
+          utilidade.</para>
+
+        <para>Novamente, as políticas de projeto variam enormemente ao
+          abordar sobre exatamente quando é adequado criar um ramo de
+          novos recursos.  Alguns projetos nunca usam ramos de recursos
+          como um todo: submissões de alterações em
+          <filename>/trunk</filename> são permitidas a todos.  A
+          vantagem deste sistema é sua simplicidade—ninguém
+          precisa aprender sobre fusões ou ramificações.  A desvantagem
+          é que o código no tronco está frequentemente instável ou
+          inutilizável.  Outros projetos usam ramos ao extremo: as
+          alterações <emphasis>nunca</emphasis> são submetidas
+          diretamente para o tronco.  Mesmo as modificações mais
+          triviais são criadas em um pequeno ramo de curta duração, são
+          cuidadosamente revistas e mescladas para o tronco.  Então o
+          ramo é excluído.  O sistema garante que o código presente no
+          tronco esteja excepcionalmente sempre estável e utilizável a
+          cada momento, mas a um curso de uma tremenda sobrecarga no
+          processo.</para>
+
+        <para>Muitos projetos utilizam uma abordagem meio-termo.  São
+          projetos que insistem que o código presente em
+          <filename>/trunk</filename> compile e passe em testes de
+          regressão a cada momento.  Um ramo de novos recursos só é
+          necessário quando uma modificação demanda um grande número de
+          submissões que possam desestabilizar o código.  Uma regra de
+          ouro é se perguntar: se o desenvolvedor trabalhou vários dias
+          isoladamente e então submeteu uma grande alteração toda de uma
+          só vez (de forma que <filename>/trunk</filename> nunca esteve
+          desestabilizada), tal modificação seria muito grande para uma
+          revisão?  Se a resposta a esta pergunta for
+          <quote>sim</quote>, então a modificação deveria ser
+          desenvolvida em um ramo de novos recursos.  Se o desenvolvedor
+          submeter modificações incrementais ao ramo, elas podem ser
+          facilmente revistas por seus colegas.</para>
+
+        <para>Finalmente, há a questão sobre o quão
+          <quote>sincronizado</quote> se deve manter um ramo de novos
+          recursos com o tronco conforme o trabalho no código for
+          avançando.  Como já mencionado anteriormente, há um grande
+          risco de se permanecer trabalhando em um ramo por semanas ou
+          meses; modificações no tronco podem continuar a acontecer, até
+          o ponto em que as duas linhas de desenvolvimento possam
+          diferir tanto a ponto de que realizar a fusão do ramo de volta
+          para o tronco possa se tornar um grande pesadelo.</para>
+
+        <para>A melhor maneira de evitar essa situação é regularmente
+          mesclar as alterações do tronco para o ramo em
+          desenvolvimento.  Defina uma política: uma vez por semana,
+          realize a fusão das alterações da última semana feitas no
+          tronco para seu ramo.  Tome cuidado ao fazer isto; será
+          necessário controle manual nas fusões visando evitar o
+          problema de se realizar repetidas fusões (como descrito em
            <xref
-          linkend="svn.branchmerge.copychanges.bestprac.track"/>).
-          You'll need to write careful log messages detailing exactly
-          which revision ranges have been merged already (as
-          demonstrated in
-          <xref linkend="svn.branchmerge.commonuses.wholebr"/>).  It
-          may sound intimidating, but it's actually pretty easy to
-          do.</para>
-
-        <para>At some point, you'll be ready to merge the
-          <quote>synchronized</quote> feature branch back to the
-          trunk.  To do this, begin by doing a final merge of the
-          latest trunk changes to the branch.  When that's done, the
-          latest versions of branch and trunk will be absolutely
-          identical except for your branch changes.  So in this
-          special case, you would merge by comparing the branch with
-          the trunk:</para>
+          linkend="svn.branchmerge.copychanges.bestprac.track"/>).  Você
+          precisará escrever cuidadosamente suas mensagens de log
+          detalhando quais intervalos de revisão já foram mesclados
+          (como demonstrado em <xref
+          linkend="svn.branchmerge.commonuses.wholebr"/>).  Pode parecer
+          assustador, mas atualmente é algo muito fácil de se
+          fazer.</para>
+
+        <para>Em algum ponto, você estará pronto para fazer a fusão de
+          seu ramo <quote>sincronizado</quote> de recursos de volta para
+          o tronco.  Para fazer isto, comece fazendo uma última fusão
+          das últimas alterações presentes no tronco para seu ramo.  Ao
+          terminar, as últimas versões do ramo e do tronco serão
+          absolutamente idênticas, exceto pelas suas próprias
+          alterações.  Assim, particularmente neste caso, você realizar
+          a fusão comparando seu ramo com o tronco:</para>

          <screen>
  $ cd trunk-working-copy
@@ -1763,20 +1780,21 @@
  …
  </screen>

-        <para>By comparing the <literal>HEAD</literal> revision of the
-          trunk with the <literal>HEAD</literal> revision of the
-          branch, you're defining a delta that describes only the
-          changes you made to the branch; both lines of development
-          already have all of the trunk changes.</para>
-
-        <para>Another way of thinking about this pattern is that your
-          weekly sync of trunk to branch is analogous to running
-          <command>svn update</command> in a working copy, while the
-          final merge step is analogous to running <command>svn
-          commit</command> from a working copy.  After all, what else
-          <emphasis>is</emphasis> a working copy but a very shallow
-          private branch?  It's a branch that's only capable of
-          storing one change at a time.</para>
+        <para>Comparando a revisão <literal>HEAD</literal> do tronco com
+          a revisão revision <literal>HEAD</literal> do ramo, você está
+          definindo um delta que descreve apenas as alterações que você
+          fez no ramo; ambas as linhas de desenvolvimento já possuem
+          todas as alterações do tronco.</para>
+
+        <para>Outra forma de pensar sobre este padrão é que sua
+          sincronização semanal do tronco para o ramo é análoga à
+          execução de um <command>svn update</command> na cópia de
+          trabalho, ao passo que o passo da fusão final é análogo a
+          executar um <command>svn commit</command> a partir de sua
+          cópia de trabalho.  E no fim das contas, o que de fato
+          <emphasis>é</emphasis> uma cópia de trabalho senão um rasteiro
+          ramo particular?  É um ramo que só é capaz de armazenar só uma
+          modificação por vez.</para>

        </sect3>



More information about the svn-pt_br mailing list