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

codesite-noreply at google.com codesite-noreply at google.com
Sun Oct 26 20:22:19 CDT 2008


Author: valeriow
Date: Sun Oct 26 18:21:44 2008
New Revision: 222

Modified:
    trunk/book/ch05-repository-admin.xml

Log:
Tradução do capítulo 5 Repository Administration (Administração do  
Repositório)
  * Seção Planning Your Repository Organization (Planejando a Organização do  
Repositório)

Modified: trunk/book/ch05-repository-admin.xml
==============================================================================
--- trunk/book/ch05-repository-admin.xml	(original)
+++ trunk/book/ch05-repository-admin.xml	Sun Oct 26 18:21:44 2008
@@ -175,96 +175,90 @@

      <!-- ===============================================================  
-->
      <sect2 id="svn.reposadmin.projects.chooselayout">
-      <title>Planning Your Repository Organization</title>
+      <title>Planejando a Organização do Repositório</title>

-      <para>While Subversion allows you to move around versioned files
-        and directories without any loss of information, and even
-        provides ways of moving whole sets of versioned history from
-        one repository to another, doing so can greatly disrupt the
-        workflow of those who access the repository often and come to
-        expect things to be at certain locations.  So before creating
-        a new repository, try to peer into the future a bit; plan
-        ahead before placing your data under version control.  By
-        conscientiously <quote>laying out</quote> your repository or
-        repositories and their versioned contents ahead of time, you
-        can prevent many future headaches.</para>
-
-      <para>Let's assume that as repository administrator, you will be
-        responsible for supporting the version control system for
-        several projects.  Your first decision is whether to use a
-        single repository for multiple projects, or to give each
-        project its own repository, or some compromise of these
-        two.</para>
-
-      <para>There are benefits to using a single repository for
-        multiple projects, most obviously the lack of duplicated
-        maintenance.  A single repository means that there is one set
-        of hook programs, one thing to routinely backup, one thing to
-        dump and load if Subversion releases an incompatible new
-        version, and so on.  Also, you can move data between projects
-        easily, and without losing any historical versioning
-        information.</para>
-
-      <para>The downside of using a single repository is that
-        different projects may have different requirements in terms of
-        the repository event triggers, such as needing to send commit
-        notification emails to different mailing lists, or having
-        different definitions about what does and does not constitute
-        a legitimate commit.  These aren't insurmountable problems, of
-        course—it just means that all of your hook scripts have
-        to be sensitive to the layout of your repository rather than
-        assuming that the whole repository is associated with a single
-        group of people.  Also, remember that Subversion uses
-        repository-global revision numbers.  While those numbers don't
-        have any particular magical powers, some folks still don't
-        like the fact that even though no changes have been made to
-        their project lately, the youngest revision number for the
-        repository keeps climbing because other projects are actively
-        adding new revisions.
+      <para>Embora o Subversion permita que você mova arquivos
+      	e diretórios versionados sem qualquer perda de informação, e até  
mesmo
+      	provê meios de mover conjuntos inteiros de eventos históricos  
versionados
+      	de um repositório para outro, fazer isso pode atrapalhar  
significativamente o
+      	fluxo de trabalho daqueles que acessam o repositório frequentemente  
e
+      	esperam que algumas coisas estejam em certos lugares. Então antes
+      	de criar um novo repositório, tente olhar um pouco para o futuro;  
pense
+      	a diante antes de colocar seus dados no controle de versão.  
Planejando
+      	conscientemente o <quote>leiaute</quote> do repositório, ou  
repositórios,
+      	e seu conteúdo versionado antes do tempo, você pode previnir muitas
+      	dores-de-cabeça futuras.</para>
+
+      <para>Vamos assumir que como administrador de repositório você será
+      	responsável pelo suporte do sistema de controle de versões para v
+      	vários projetos. Sua primeira decisão é se usará um único  
repositório
+      	para múltiplos projetos, ou fornecer para cada projeto o seu próprio
+      	repositório, ou ainda alguma combinação disso.</para>
+
+      <para>Existem vantagens em se utilizar um único repositório para
+      	múltiplos projetos e a mais óbvia é a ausência de manutenção
+      	duplicada. Um único repositório significa que haverá um único  
conjunto
+      	de programas de gatilhos, uma única coisa para fazer cópias de  
segurança
+      	periódicas, uma única coisa para descarregar e carregar se o  
Subversion
+      	lança um nova versão incompatível, e por aí vai. Além disso, você  
pode
+      	mover dados entre projetos facilmente, e sem perder qualquer  
informação
+      	de versionamento.</para>
+
+      <para>A desvantagem de usar um único repositório é que
+      	diferentes projetos podem ter diferentes requisitos em termos de
+      	gatilhos de eventos, como por exemplo a necessidade de enviar
+      	notificações de submissão para diferentes listas de e-mail, ou ter
+      	diferentes definições sobre o que constitui uma sumissão correta. É  
claro
+      	que eles não são problemas insuperáveis—somente significa que
+      	todos os seus scripts de gatilho devem ser sensíveis ao leiaute
+      	do seu repositório ao invés de assumir que todo o repositório está
+      	assoicado com um único grupo de pessoas. Além disso, lembre-se que
+      	o Subversion usa números de revisão globais com relação ao  
repositório.
+      	Muito embora esses números não tenham particularmente nenhum poder  
mágico,
+      	algumas pessoas continuam não gostando do fato de que mesmo que não  
haja
+      	modificações no seu projeto recentemente o número de revisão  
continua
+      	sendo incrementado porque outros projetos continuam adicionando
+      	novas revisões.
          <footnote>
-          <para>Whether founded in ignorance or in poorly considered
-            concepts about how to derive legitimate software
-            development metrics, global revision numbers are a silly
-            thing to fear, and <emphasis>not</emphasis> the kind of
-            thing you should weigh when deciding how to arrange your
-            projects and repositories.</para>
+          <para>Quer seja baseado na ignorância ou em fracos conceitos
+          	sobre como produzir métricas de desenvolvimento corretamente,
+          	números de revisões globais são uma coisa tola para temer, e
+          	<emphasis>não</emphasis> o tipo de coisa que você deveria pesar
+          	na hora de decidir como organizar seus projetos e  
repositórios.</para>
          </footnote>
        </para>

-      <para>A middle-ground approach can be taken, too.  For example,
-        projects can be grouped by how well they relate to each other.
-        You might have a few repositories with a handful of projects
-        in each repository.  That way, projects that are likely to
-        want to share data can do so easily, and as new revisions are
-        added to the repository, at least the developers know that
-        those new revisions are at least remotely related to everyone
-        who uses that repository.</para>
-
-      <para>After deciding how to organize your projects with respect
-        to repositories, you'll probably want to think about directory
-        hierarchies within the repositories themselves.  Because
-        Subversion uses regular directory copies for branching and
-        tagging (see <xref linkend="svn.branchmerge"/>), the
-        Subversion community recommends that you choose a repository
-        location for each <firstterm>project
-        root</firstterm>—the <quote>top-most</quote> directory
-        which contains data related to that project—and then
-        create three subdirectories beneath that root:
-        <filename>trunk</filename>, meaning the directory under which
-        the main project development occurs;
-        <filename>branches</filename>, which is a directory in which
-        to create various named branches of the main development line;
-        <filename>tags</filename>, which is a collection of tree
-        snapshots that are created, and perhaps destroyed, but never
-        changed.
+      <para>Uma abordagem meio termo pode ser utilizada também. Por  
exemplo,
+      	projetos podem ser agrupados pela forma como eles se relacionam  
entre si.
+      	Você pode ter alguns poucos repositórios com um punhado de projetos
+      	em cada um deles. Dessa forma, projetos nos quais é desejável o  
compartilhamento
+      	de dados podem fazê-lo facilmente, e quando novas revisões são  
adicionadas
+      	ao repositório, os desenvolvedores saberão que essas revisões são no
+      	mínimo remotamente relacionadas com todos que usam esse  
repositório.</para>
+
+      <para>Depois de decidir como organizar seus projetos com relação
+      	aos repositórios você irá provavelmente pensar sobre a hierarquia
+      	de diretórios lá dentro. Como o Subversion utiliza cópias comuns
+      	de diretórios para ramificações  
(<foreignphrase>branches</foreignphrase>)
+      	e rótulos (<foreignphrase>tags</foreignphrase>) (veja <xref  
linkend="svn.branchmerge"/>),
+      	a comunidade recomenda que você escolha uma localização para cada
+      	<firstterm>raiz de projeto</firstterm>—o <quote>mais  
alto</quote>
+      	diretório que irá conter dados relacionados com o projeto—e  
então
+      	criar três subdiretórios abaixo desse raiz:
+        <filename>trunk</filename>, o diretório no qual o desenvolvimento
+        principal do projeto ocorre;
+        <filename>branches</filename>, diretório no podem ser criados  
vários ramos
+        da linha principal de desenvolvimento;
+        <filename>tags</filename>, diretório que poderá conter uma coleção  
instantâneos de árvores
+        de diretório que são criados, e possivelmente destroídos, mas  
nunca alterados.
          <footnote>
-          <para>The <filename>trunk</filename>, <filename>tags</filename>,
-            and <filename>branches</filename> trio are sometimes referred
-            to as <quote>the TTB directories</quote>.</para>
+          <para>O trio <filename>trunk</filename>,  
<filename>tags</filename>,
+            and <filename>branches</filename> são muitas vezes chamados de
+            <quote>diretórios TTB</quote>.</para>
          </footnote>
          </para>

-      <para>For example, your repository might look like:</para>
+      <para>Por exemplo, seu repositório poderá se parecer com o  
seguinte:</para>

        <screen>
  /
@@ -283,15 +277,15 @@
     …
  </screen>

-      <para>Note that it doesn't matter where in your repository each
-        project root is.  If you have only one project per repository,
-        the logical place to put each project root is at the root of
-        that project's respective repository.  If you have multiple
-        projects, you might want to arrange them in groups inside the
-        repository, perhaps putting projects with similar goals or
-        shared code in the same subdirectory, or maybe just grouping
-        them alphabetically.  Such an arrangement might look
-        like:</para>
+      <para>Note que não importa onde está cada raiz de projeto
+      	no seu repositório. Se você possuir somente um único projeto
+      	por repositório, o lugar mais lógico para colocar cada
+      	raiz de projeto é na raiz do respectivo repositório do projeto.
+      	Se você possui múltiplos projetos, você pode querer organizá-los
+      	em grupos dentro do repositório, talvez colocando projetos com
+      	objetivos semelhantes ou código compartilhado no mesmo subdiretório,
+      	ou talvez simplesmente agrupá-los alfabeticamente. Tal organização
+      	poderia se parecer com o que segue: </para>

        <screen>
  /
@@ -313,19 +307,18 @@
        …
  </screen>

-      <para>Lay out your repository in whatever way you see fit.
-        Subversion does not expect or enforce a particular layout—in
-        its eyes, a directory is a directory is a directory.
-        Ultimately, you should choose the repository arrangement that
-        meets the needs of the people who work on the projects that
-        live there.</para>
-
-      <para>In the name of full disclosure, though, we'll mention
-        another very common layout.  In this layout, the
-        <filename>trunk</filename>, <filename>tags</filename>, and
-        <filename>branches</filename> directories live in the root
-        directory of your repository, and your projects are in
-        subdirectories beneath those, like:</para>
+      <para>Organize seu repositório da forma que você preferir.
+      	Subversion não espera ou força uma organização particular—
+      	na sua visão, um diretório é um diretório.
+      	No final das contas você deve escolher a organização de
+      	repositório que atende as necessidades das pessoas que trabalham
+      	nos projetos que irão viver lá.</para>
+
+      <para>Em nome da revelação completa, no entanto, nós iremos
+      	mencionar outra forma muito comum de organizção. Nesse leiaute	
+        os diretórios <filename>trunk</filename>, <filename>tags</filename>
+        e <filename>branches</filename> residem no diretório raiz do
+        repositório e os projetos estão em subdiretórios abaixo deles,  
como:</para>

        <screen>
  /
@@ -346,20 +339,20 @@
        …
  </screen>

-      <para>There's nothing particularly incorrect about such a
-        layout, but it may or may not seem as intuitive for your
-        users.  Especially in large, multi-project situations with
-        many users, those users may tend to be familiar with only one
-        or two of the projects in the repository.  But the
-        projects-as-branch-siblings tends to de-emphasize project
-        individuality and focus on the entire set of projects as a
-        single entity.  That's a social issue though.  We like our
-        originally suggested arrangement for purely practical
-        reasons—it's easier to ask about (or modify, or migrate
-        elsewhere) the entire history of a single project when there's
-        a single repository path that holds the entire
-        history—past, present, tagged, and branched—for
-        that project and that project alone.</para>
+      <para>Não existe nada de incorreto nessa forma de organização,
+      mas ela pode ou não parecer intuitiva para seus usuários.
+      Especialmente em situações de vários e grandes projetos com muitos
+      usuários, esses usuários podem tender a se familiarizar com
+      somente um ou dois projetos no repositório. Utilizar projetos como
+      ramos irmãos tende a desenfatizar a individualidade dos projetos
+      e focar no conjunto inteiro como uma única entidade. De qualquer
+      forma essa é uma questão social. Nós gostamos da organização
+      inicialmente proposta por razões puramente práticas—é fácil
+      perguntar sobre (ou modificar, ou migrar para outro lugar)
+      o histórico completo de um único projeto quando existe um único
+      caminho no repositório que guarda tudo—
+      passado, presente, etiquetas, and ramos—referente ao
+      projeto sozinho.</para>

      </sect2>

@@ -2952,7 +2945,7 @@
  	nessa tarefa. Ao longo desse capítulo, nós mostramos
  	obstáculos comuns e sugestões para evitá-los.</para>

-    <para>Tudo que falta é para você é decidir que tipo de informação
+    <para>Tudo que falta para você é decidir que tipo de informação
  	armazenar no seu repositório, e finalmente, como deixá-lo
  	disponível na rede. O próximo capítulo é todo sobre rede.</para>



More information about the svn-pt_br mailing list