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

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


Author: camponez
Date: Tue Mar 18 19:22:25 2008
New Revision: 47

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

Log:
Parte do issue 39

Modified: trunk/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/book/ch04-branching-and-merging.xml	(original)
+++ trunk/book/ch04-branching-and-merging.xml	Tue Mar 18 19:22:25 2008
@@ -1875,111 +1875,104 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.tags">
-    <title>Tags</title>
+    <title>Rótulos</title>
 
-    <para>Another common version control concept is a
-      <firstterm>tag</firstterm>.  A tag is just a
-      <quote>snapshot</quote> of a project in time.  In Subversion,
-      this idea already seems to be everywhere.  Each repository
-      revision is exactly that—a snapshot of the filesystem
-      after each commit.</para>
-
-    <para>However, people often want to give more human-friendly names
-      to tags, like <literal>release-1.0</literal>.  And they want to
-      make snapshots of smaller subdirectories of the filesystem.
-      After all, it's not so easy to remember that release-1.0 of a
-      piece of software is a particular subdirectory of revision
-      4822.</para>
+    <para>Outro conceito comum do controle de versão é <firstterm>ramo</firstterm>.
+	Um ramo é apenas uma <quote>foto</quote> do projeto no momento. No Subversion,
+	essa idéia parece estar em todo lugar. Cada revisão do repositório é 
+	exatamente isso—uma foto da estrutura depois de 
+	cada commit.</para>
+
+    <para>Entretando, pessoas normalmente querem dar rótulos mais amigáveis
+	como nomes de tags, como <literal>versão-1.0</literal>. E querem
+	fazer <quote>fotos</quote> de pequenos sub-diretórios da estrutura.
+	Além do mais, não é fácil lembrar que versão-1.0 de um pedaço do
+	software é um particular sub-diretório da revisão 4822.</para>	
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mksimple">
-      <title>Creating a Simple Tag</title>
+      <title>Criando um rótulo simples</title>
 
-      <para>Once again, <command>svn copy</command> comes to the
-        rescue.  If you want to create a snapshot of
-        <filename>/calc/trunk</filename> exactly as it looks in the
-        <literal>HEAD</literal> revision, then make a copy of it:</para>
+      <para>Mais uma vez, <command>snv copy</command> vem para nos
+	  socorrer. Se você quer criar uma foto do <filename>/calc/trunk</filename>
+	  exatamente como ele está na revisão <literal>HEAD</literal>, 
+	  fazendo uma copia dela:</para>
 
       <screen>
 $ svn copy http://svn.example.com/repos/calc/trunk \
            http://svn.example.com/repos/calc/tags/release-1.0 \
-      -m "Tagging the 1.0 release of the 'calc' project."
+      -m "Rótulando a versão 1.0 do projeto 'calc'."
 
 Committed revision 351.
 </screen>
 
-      <para>This example assumes that a
-        <filename>/calc/tags</filename> directory already exists.  (If
-        it doesn't, you can create it using <command>svn
-        mkdir</command>.)  After the copy completes, the new
-        <filename>release-1.0</filename> directory is forever a
-        snapshot of how the project looked in the
-        <literal>HEAD</literal> revision at the time you made the
-        copy.  Of course you might want to be more precise about
-        exactly which revision you copy, in case somebody else may
-        have committed changes to the project when you weren't
-        looking.  So if you know that revision 350 of
-        <filename>/calc/trunk</filename> is exactly the snapshot you
-        want, you can specify it by passing <option>-r 350</option> to
-        the <command>svn copy</command> command.</para>
-
-      <para>But wait a moment: isn't this tag-creation procedure the
-        same procedure we used to create a branch?  Yes, in fact, it
-        is.  In Subversion, there's no difference between a tag and a
-        branch.  Both are just ordinary directories that are created
-        by copying.  Just as with branches, the only reason a copied
-        directory is a <quote>tag</quote> is because
-        <emphasis>humans</emphasis> have decided to treat it that way:
-        as long as nobody ever commits to the directory, it forever
-        remains a snapshot.  If people start committing to it, it
-        becomes a branch.</para>
-
-      <para>If you are administering a repository, there are two
-        approaches you can take to managing tags.  The first approach
-        is <quote>hands off</quote>: as a matter of project policy,
-        decide where your tags will live, and make sure all users know
-        how to treat the directories they copy in there.  (That is,
-        make sure they know not to commit to them.)  The second
-        approach is more paranoid: you can use one of the
-        access-control scripts provided with Subversion to prevent
-        anyone from doing anything but creating new copies in the
-        tags-area (See <xref linkend="svn.serverconfig"/>.)  The paranoid
-        approach, however, isn't usually necessary.  If a user
-        accidentally commits a change to a tag-directory, you can
-        simply undo the change as discussed in the previous section.
-        This is version control, after all.</para>
+    <para>Este exemplo assume que o diretório <filename>/calc/tags</filename> 
+    já existe.
+    (Se ele não existir, você pode criá-lo usando <command>svn mkdir</command>.)
+    Depois da copia completar, o novo diretório <filename>versão-1.0</filename>
+    será para sempre uma foto de como o projeto estava na revisão
+    <literal>HEAD</literal> no momento que a copia foi feita. Claro 
+    que você pode querer mais precisão em saber qual revisão a copia foi 
+    feita, em caso de alguém ter feito commit no projeto quando você não 
+    estava vendo. Então se você sabe que a revisão 350 do 
+    <filename>/calc/trunk</filename> é exatamente a foto que você quer,
+    você pode especificar isso passando <option>-r 350</option>
+    para o comando <command>svn copy</command>.</para> 
+
+    <para>Mas espere um pouco: não é essa criação do rótulo o mesmo procedimento
+    para criar um ramo? Sim, de fato, é. No Subversion, não há diferença
+    entre um rótulo e um ramo. Assim como com ramos, a única razão uma 
+    cópia é um <quote>rótulo</quote> é porque <emphasis>humanos</emphasis>
+    decidiram tratar isso desse jeito: desde que ninguém nunca faça commit
+    para esse diretório, ele permanecerá para sempre uma foto. Se as pessoas
+    começarem a fazer commit para ele, ele se transoforma num ramo.</para>
+
+    <para>Se você está administrando um repositório, existe duas maneiras
+	para gerenciar rótulos. A primeira é <quote>não toque</quote>:
+	como uma política do projeto, decida onde os rótulos vão morar,
+	e garanta que todos os usuários saibam como tratar os diretórios
+	que eles vão copiar para lá. (Isso quer dizer, garanta que 
+	eles saibam que não devem fazer neles.) A segunda é mais paranóica:
+	você pode usar um dos scripts de controle de acesso providos com 
+	o Subversion para previnir que alguém faça algo além de apenas
+	criar novas copias na área de rótulos (Veja <xref linkend="svn.serverconfig"/>.)
+	A maneira paranoica, entrentanto, não é necessária. Se algum
+	usuário acidentalmente fizer commit de alguam mudança
+	para o diretório de rótulo, você pode simplesmente desfazer
+	a mudança como discutido na revisção anterior. É um controle
+	de versão apesar de tudo.</para>
+
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mkcomplex">
-      <title>Creating a Complex Tag</title>
+      <title>Criando um rótulo complexo</title>
+
+      <para>Algumas vezes você que sua <quote>foto</quote> seja mais 
+	  complicada que um simples diretório de uma única revisão.</para>
 
-      <para>Sometimes you may want your <quote>snapshot</quote> to be
-        more complicated than a single directory at a single
-        revision.</para>
-
-      <para>For example, pretend your project is much larger than our
-        <filename>calc</filename> example: suppose it contains a
-        number of subdirectories and many more files.  In the course
-        of your work, you may decide that you need to create a working
-        copy that is designed to have specific features and bug fixes.
-        You can accomplish this by selectively backdating files or
-        directories to particular revisions (using <command>svn update
-        -r</command> liberally), or by switching files and directories
-        to particular branches (making use of <command>svn
-        switch</command>).  When you're done, your working copy is a
-        hodgepodge of repository locations from different revisions.
-        But after testing, you know it's the precise combination of
-        data you need.</para>
-
-      <para>Time to make a snapshot.  Copying one URL to another won't
-        work here.  In this case, you want to make a snapshot of your
-        exact working copy arrangement and store it in the repository.
-        Luckily, <command>svn copy</command> actually has four
-        different uses (which you can read about in <xref
-        linkend="svn.ref"/>), including the ability to copy a
-        working-copy tree to the repository:</para>
+      <para>Por exemplo, pense que seu projeto é muito maior que nosso
+	  exemplo <filename>calc</filename>: suponha que contém um 
+	  número de sub-diretórios e muitos outros arquivos. No curso 
+	  do seu trabalho, você pode decidir que você precisa criar um
+	  cópia de trabalho que é destinado para novos recursos e 
+	  correções de erros. Você pode conseguir isso selecionando
+	  arquivos e diretórios com datas anteriores em uma revisão
+	  particular (usando <command>svn update -r </command> livremente),
+	  ou mudando arquivos e diretórios para um ramo em particular
+	  (fazendo uso do <command>svn switch</command>). Quando estiver
+	  pronto, sua cópia de trabalho será uma mistura de diferentes 
+	  revisões. Mas depois de testes, você saberá que é exatamente
+	  a combinação que você precisa.</para>
+
+      <para>Hora de fazer a foto. Copiar uma URL para outra não vai 
+	  funcionar aqui. Nesse caso, você quer fazer uma foto exata
+	  da cópia de trabalho que você organizou e armazenar no 
+	  repositório. Felizmente, <command>svn copy</command> na verdade
+	  tem quatro diferentes maneiras de ser usado (você pode ler sobre
+	  em <xref linkend="svn.ref"/>), incluindo a habilidade de copiar
+	  uma árvore de cópia de trablho para o respositório:</para>
 
       <screen>
 $ ls
@@ -1990,11 +1983,23 @@
 Committed revision 352.
 </screen>
 
-      <para>Now there is a new directory in the repository,
-        <filename>/calc/tags/mytag</filename>, which is an exact
-        snapshot of your working copy—mixed revisions, URLs,
-        and all.</para>
-
+	<para>Agora existe um novo diretório no respositório
+	<filename>/calc/tags/mytag</filename>, que é uma foto exata
+	da sua cópia de trabalho—combinado revisões, URLs, e 
+	tudo mais.</para>
+
+    <para>Outros usuários tem encontrado usos interessantes para esse
+	recurso. Algumas vezes existe situações onde você tem um monte
+	de mudanças locais na sua cópia de trabalho, e você gostaria
+	que um colega de trabalho as visse. Ao invés de usar 
+	<command>svn diff</command> e enviar o arquivo patch (que 
+	não irá ter as informações de mudança na árvore de diretórios,
+	em symlink e mudanças nas propriedades), você pode usar 
+	<command>svn copy</command> para <quote>subir</quote> 
+	sua cópia local para uma área privada no repositório. Seu colega
+	pode verificar o nome de cópia da sua cópia de trabalho, ou
+	usar <command>svn merge</command> para receber as exatas
+	mudanças.</para>	
       <para>Other users have found interesting uses for this feature.
         Sometimes there are situations where you have a bunch of local
         changes made to your working copy, and you'd like a




More information about the svn-pt_br mailing list