[svnbook-pt-br commit] r359 - trunk/book
codesite-noreply at google.com
codesite-noreply at google.com
Wed Dec 24 23:57:10 CST 2008
Author: mfandrade
Date: Wed Dec 24 21:06:10 2008
New Revision: 359
Modified:
trunk/book/ch05-repository-admin.xml
Log:
Tradução do capítulo 5, ""Administração do Repositório", seção "Manutenção
do Repositório", demais parágrafos da subseção "Replicação do Repositório".
Modified: trunk/book/ch05-repository-admin.xml
==============================================================================
--- trunk/book/ch05-repository-admin.xml (original)
+++ trunk/book/ch05-repository-admin.xml Wed Dec 24 21:06:10 2008
@@ -2483,91 +2483,95 @@
repositório de destino.</para>
<note>
- <para>When using <command>svnsync</command> against a remote
- source repository, the Subversion server for that repository
- must be running Subversion version 1.4 or better.</para>
+ <para>Quando estiver usando o <command>svnsync</command> com um
+ repositório de origem remoto, o servidor do Subversion daquele
+ repositório deve estar executando o Subversion na versão 1.4
+ ou posterior.</para>
</note>
- <para>Assuming you already have a source repository that you'd
- like to mirror, the next thing you need is an empty target
- repository which will actually serve as that mirror. This
- target repository can use either of the available filesystem
- data-store back-ends (see <xref
- linkend="svn.reposadmin.basics.backends" />), but it must not
- yet have any version history in it. The protocol via which
- <command>svnsync</command> communicates revision information
- is highly sensitive to mismatches between the versioned
- histories contained in the source and target repositories.
- For this reason, while <command>svnsync</command> cannot
- <emphasis>demand</emphasis> that the target repository be
- read-only,
+ <para>Assumindo que você já tenha um repositório de origem que
+ gostaria de espelhar, a próxima coisa que você precisa é de um
+ repositório de destino vazio que irá servir de espelho. Este
+ repositório de destino pode até mesmo usar sistemas de
+ armazenamento baseado em arquivo (veja <xref
+ linkend="svn.reposadmin.basics.backends" />), mas não deve ter
+ nenhum histórico de versão dentro de si. O protocolo com o qual
+ o <command>svnsync</command> comunica informações de revisão é
+ altamente sensível a diferenças entre históricos versionados
+ contidos nos repositórios de origem e destino. Por este motivo,
+ ainda que o <command>svnsync</command> não
+ <emphasis>precise</emphasis> que o servidor de destino seja
+ somente-leitura,
<footnote>
- <para>In fact, it can't truly be read-only, or
- <command>svnsync</command> itself would have a tough time
- copying revision history into it.</para>
+ <para>De fato, ele não poderia ser verdadeiramente
+ somente-leitura, ou o próprio <command>svnsync</command>
+ não teria que demandar uma dura tarefa de copiar o histórico
+ de revisões para si.</para>
</footnote>
- allowing the revision history in the target repository to
- change by any mechanism other than the mirroring process is a
- recipe for disaster.</para>
+ permitir que o histórico de revisões no repositório de destino
+ sofra alguma mudança devido a qualquer outro mecanismo que não o
+ processo de espelhamento é uma receita para um desastre.</para>
<warning>
- <para>Do <emphasis>not</emphasis> modify a mirror repository
- in such a way as to cause its version history to deviate
- from that of the repository it mirrors. The only commits
- and revision property modifications that ever occur on that
- mirror repository should be those performed by the
- <command>svnsync</command> tool.</para>
+ <para><emphasis>Nunca</emphasis> modifique um repositório
+ espelho de maneira a fazer com que seu histórico de versões
+ difira daquele do repositório o qual é espelhado. As únicas
+ submissões e modificações de propriedades de revisão que devem
+ ocorrer no repositório espelho devem ser feitas exclusivamente
+ pela ferramenta <command>svnsync</command>.</para>
</warning>
- <para>Another requirement of the target repository is that the
- <command>svnsync</command> process be allowed to modify
- certain revision properties. <command>svnsync</command>
- stores its bookkeeping information in special revision
- properties on revision 0 of the destination repository.
- Because <command>svnsync</command> works within the framework
- of that repository's hook system, the default state of the
- repository (which is to disallow revision property changes;
- see <xref linkend="svn.ref.reposhooks.pre-revprop-change" />)
- is insufficient. You'll need to explicitly implement the
- pre-revprop-change hook, and your script must allow
- <command>svnsync</command> to set and change its special
- properties. With those provisions in place, you are ready to
- start mirroring repository revisions.</para>
+ <para>Outro requisito para o repositório de destino é que o
+ processo <command>svnsync</command> tenha permissão de modificar
+ certas propriedades de revisão. O <command>svnsync</command>
+ armazena suas informações gerenciais em propriedades de revisão
+ especiais na revisão 0 do repositório de destino. Como o
+ <command>svnsync</command> opera de dentro do framework do
+ sistema de scripts de hook daquele repositório, o estado padrão
+ do repositório (que é proibir modificações de propriedades; veja
+ <xref linkend="svn.ref.reposhooks.pre-revprop-change" />) é
+ insuficiente. Você vai precisar implementar explicitamente o
+ script de hook pre-revprop-change hook, e seu script deve
+ permitir que o <command>svnsync</command> atribua e modifique
+ suas propriedades especiais. Com a efetivação destas medidas,
+ você está pronto para começar a espelhar as revisões de seu
+ repositório.</para>
<tip>
- <para>It's a good idea to implement authorization measures
- which allow your repository replication process to perform
- its tasks while preventing other users from modifying the
- contents of your mirror repository at all.</para>
+ <para>É uma boa idéia implementar medidas de autorização que
+ permitam que o processo de réplica de seu repositório execute
+ suas tarefas ao mesmo tempo em que impede outros usuários de
+ modificar o conteúdo do repositório espelho como um
+ todo.</para>
</tip>
- <para>Let's walk through the use of <command>svnsync</command>
- in a somewhat typical mirroring scenario. We'll pepper this
- discourse with practical recommendations which you are free to
- disregard if they aren't required by or suitable for your
- environment.</para>
-
- <para>As a service to the fine developers of our favorite
- version control system, we will be mirroring the public
- Subversion source code repository and exposing that mirror
- publicly on the Internet, hosted on a different machine than
- the one on which the original Subversion source code
- repository lives. This remote host has a global configuration
- which permits anonymous users to read the contents of
- repositories on the host, but requires users to authenticate
- in order to modify those repositories. (Please forgive us for
- glossing over the details of Subversion server configuration
- for the moment—those are covered thoroughly in <xref
- linkend="svn.serverconfig" />.) And for no other reason than
- that it makes for a more interesting example, we'll be driving
- the replication process from a third machine, the one which
- we currently find ourselves using.</para>
-
- <para>First, we'll create the repository which will be our
- mirror. This and the next couple of steps do require shell
- access to the machine on which the mirror repository will
- live. Once the repository is all configured, though, we
- shouldn't need to touch it directly again.</para>
+ <para>Vamos avançar ao uso do <command>svnsync</command> em um
+ cenário típico de espelhamento. Vamos apimentar este discurso
+ com recomendações práticas as quais você tem liberdade para
+ desconsiderar se elas não forem necessárias ou não se aplicarem
+ a seu ambiente.</para>
+
+ <para>Como um serviço aos grandes desenvolvedores de nosso sistema
+ de controle de versão favorito, vamos espelhar o repositório do
+ código-fonte do Subversion e disponibilizar este espelho
+ publicamente na Internet, hospedado em uma máquina diferente
+ daquela onde se encontra o código-fonte original. Este host
+ remoto tem uma configuração global que permite que usuários
+ anônimos leiam o conteúdo dos repositórios no host, mas
+ necessita que os usuários se autentiquem para submeter
+ alterações nesses repositórios. (Por favor, perdoe-nos por não
+ mencionarmos os detalhes da configuração do servidor do
+ Subversion neste momento—alguns deles são plenamente
+ abordados em <xref linkend="svn.serverconfig" />.) E apenas
+ para deixar este exemplo ainda mais interessante, vamos conduzir
+ o processo de replicação também para uma terceira máquina, a
+ qual atualmente estamos utilizando efetivamente.</para>
+
+ <para>Primeiro, vamos criar o repositório que será o nosso
+ espelho. Este e alguns dos próximos passos seguintes necessitam
+ de acesso ao shell da máquina na qual o repositório irá ficar.
+ Uma vez que o repositórios esteja todo configurado, porém, não
+ precisaremos mais mexer diretamente nele de novo.</para>
<screen>
$ ssh admin at svn.example.com \
@@ -2576,30 +2580,32 @@
$
</screen>
- <para>At this point, we have our repository, and due to our
- server's configuration, that repository is now
- <quote>live</quote> on the Internet. Now, because we don't
- want anything modifying the repository except our replication
- process, we need a way to distinguish that process from other
- would-be committers. To do so, we use a dedicated username
- for our process. Only commits and revision property
- modifications performed by the special username
- <literal>syncuser</literal> will be allowed.</para>
-
- <para>We'll use the repository's hook system both to allow the
- replication process to do what it needs to do, and to enforce
- that only it is doing those things. We accomplish this by
- implementing two of the repository event
- hooks—pre-revprop-change and start-commit. Our
- <filename>pre-revprop-change</filename> hook script is found
- in <xref
+ <para>Neste ponto, temos nosso repositórios, e pela configuração
+ de nosso servidor, esse repositório agora está
+ <quote>ativo</quote> na Internet. Agora, como nós não queremos
+ que nada mais modifique o repositório além de nosso processo
+ replicador, precisamos de alguma forma distinguir esse processo
+ de outros aspirantes a submissores de modificações. Para isso,
+ vamos usar um nome de usuário dedicado para nosso processo.
+ Apenas as submissões e modificações de propriedades de revisão
+ executadas pelo nome de usuário especial
+ <literal>syncuser</literal> serão permitidas.</para>
+
+ <para>Vamos usar o sistema de scripts de hook do repositório para
+ permitir que o processo de replicação faça tudo o que precisa
+ fazer, e garantir que faça tão somente essas coisas. Fazemos
+ isso imeplementando dois dos ganchos de eventos do
+ repositório—pre-revprop-change e start-commit. Nosso
+ script <filename>pre-revprop-change</filename> é encontrado em
+ <xref
linkend="svn.reposadmin.maint.replication.pre-revprop-change"
- />, and basically verifies that the user attempting the
- property changes is our <literal>syncuser</literal> user. If
- so, the change is allowed; otherwise, it is denied.</para>
+ />, e basicamente verifica se o usuário está tentando realizar a
+ modificação de propriedade é o nosso usuário
+ <literal>syncuser</literal>. Se o for, a modificação é
+ efetivada; senão, será proibida.</para>
<example id="svn.reposadmin.maint.replication.pre-revprop-change">
- <title>Mirror repository's pre-revprop-change hook script</title>
+ <title>Script de hook pre-revprop-change para operação de
espelhamento</title>
<programlisting>
#!/bin/sh
@@ -2613,16 +2619,16 @@
</programlisting>
</example>
- <para>That covers revision property changes. Now we need to
- ensure that only the <literal>syncuser</literal> user is
- permitted to commit new revisions to the repository. We do
- this using a <filename>start-commit</filename> hook scripts
- like the one in <xref
+ <para>Isso cobre as modificações de propriedades. Agora também
+ precisamos garantir que apenas o usuário
+ <literal>syncuser</literal> tenha permissão de submeter novas
+ revisões ao repositório. Fazemos isso usando um script
+ <filename>start-commit</filename> parecido com aquele em <xref
linkend="svn.reposadmin.maint.replication.start-commit"
/>.</para>
<example id="svn.reposadmin.maint.replication.start-commit">
- <title>Mirror repository's start-commit hook script</title>
+ <title>Script de hook start-commit para operação de
espelhamento</title>
<programlisting>
#!/bin/sh
@@ -2636,22 +2642,22 @@
</programlisting>
</example>
- <para>After installing our hook scripts and ensuring that they
- are executable by the Subversion server, we're finished with
- the setup of the mirror repository. Now, we get to actually
- do the mirroring.</para>
-
- <para>The first thing we need to do with
- <command>svnsync</command> is to register in our target
- repository the fact that it will be a mirror of the source
- repository. We do this using the <command>svnsync
- initialize</command> subcommand. Note that the various
- <command>svnsync</command> subcommands provide several of the
- same authentication-related options that
- <command>svn</command> does: <option>--username</option>,
+ <para>Depois de instalar nossos scripts de hook e de garantir que
+ eles são executáveis pelo usuário do Subversion, nós terminamos
+ com a configuração do repositório espelho. Agora, vamos entrar
+ na operação de espelhamento em si.</para>
+
+ <para>A primeira coisa que precisamos fazer com o
+ <command>svnsync</command> é registrar em nosso repositório
+ destino o fato de que ele será um espelho de um outro
+ repositório origem. Fazemos isso usando subcomando
+ <command>svnsync initialize</command>. Note que os vários
+ subcomandos do <command>svnsync</command> dispõem das mesmas
+ diversas opções relativas a autenticação que o
+ <command>svn</command> possui: <option>--username</option>,
<option>--password</option>,
<option>--non-interactive</option>,
- <option>--config-dir</option>, and
+ <option>--config-dir</option>, e
<option>--no-auth-cache</option>.</para>
<screen>
@@ -2684,56 +2690,57 @@
$
</screen>
- <para>Our target repository will now remember that it is a
- mirror of the public Subversion source code repository.
- Notice that we provided a username and password as arguments
- to <command>svnsync</command>—that was required by the
- pre-revprop-change hook on our mirror repository.</para>
+ <para>Nosso repositório destino agora vai lembrar que é um espelho
+ de um repositório público do código-fonte do Subversion.
+ Perceba que informamos um nome de usuário e uma senha como
+ argumentos para o <command>svnsync</command>—o que é
+ requerido pelo script pre-revprop-change de nosso repositório
+ espelho.</para>
<note>
- <para>The URLs provided to <command>svnsync</command> must
- point to the root directories of the target and source
- repositories, respectively. The tool does not handle
- mirroring of repository subtrees.</para>
+ <para>As URLs informadas para o <command>svnsync</command> devem
+ apontar para os diretórios raízes dos repositórios de destino
+ e de origem, respectivamente. A ferramenta não manipula
+ espelhamento de sub-árvores de um repositório.</para>
</note>
<note>
- <para>The initial release of <command>svnsync</command> (in
- Subversion 1.4) has a small shortcoming—the values
- given to the <option>--username</option> and
- <option>--password</option> command-line options get used
- for authentication against both the source and destination
- repositories. Obviously, there's no guarantee that the
- synchronizing user's credentials are the same in both
- places. In the event that they are not the same, users
- trying to run <command>svnsync</command> in non-interactive
- mode (with the <option>--non-interactive</option> option)
- might experience problems.</para>
+ <para>A versão inicial do <command>svnsync</command> (no
+ Subversion 1.4) tem uma pequena deficiência—os valores
+ informados para as opções de linha de comando
+ <option>--username</option> e <option>--password</option> são
+ usado para autenticação em ambos repositórios de origem e de
+ destino. Obviamente, não há garantia de que as credenciais
+ do usuário sejam as mesmas nesses dois locais. No caso de
+ elas não serem as mesmas, os usuários que estiverem executando
+ o <command>svnsync</command> em modo não-interativo (com a
+ opção <option>--non-interactive</option>) podem ter
+ probemas.</para>
</note>
- <para>And now comes the fun part. With a single subcommand, we
- can tell <command>svnsync</command> to copy all the
- as-yet-unmirrored revisions from the source repository to the
- target.
+ <para>E agora vem a parte divertida. Com um único subcomando,
+ vamos pedir para o <command>svnsync</command> copiar todas as
+ revisões que ainda não tiverem sido espelhadas do repositório de
+ origem para o destino.
<footnote>
- <para>Be forewarned that while it will take only a few
- seconds for the average reader to parse this paragraph and
- the sample output which follows it, the actual time
- required to complete such a mirroring operation is, shall
- we say, quite a bit longer.</para>
+ <para>Esteja ciente de que ainda que levem alguns poucos
+ segundos para que um leitor mediano analise este parágrafo e
+ a saída ilustrativa que o segue, o tempo total necessário
+ para concluir uma operação de espelhamento é, como dissemos,
+ um bocado mais demorada.</para>
</footnote>
- The <command>svnsync synchronize</command> subcommand will
- peek into the special revision properties previously stored on
- the target repository, and determine what repository it is
- mirroring and that the most recently mirrored revision was
- revision 0. Then it will query the source repository and
- determine what the latest revision in that repository is.
- Finally, it asks the source repository's server to start
- replaying all the revisions between 0 and that latest
- revision. As <command>svnsync</command> get the resulting
- response from the source repository's server, it begins
- forwarding those revisions to the target repository's server
- as new commits.</para>
+ O subcomando <command>svnsync synchronize</command> irá checar
+ as propriedades de revisão especiais previamente armazenadas no
+ repositório destino, e verificar qual repositórios ele está
+ espelhando e que a revisão mais recentemente espelhada foi a
+ revisão 0. Então ele irá consultar o repositório de origem e
+ determinar qual foi a última revisão naquele repositório.
+ Finalmente, o comando solicita ao resvidor do repositório de
+ origem que comece a re-executar todas as revisões entre 0 e a
+ última revisão. Tão logo o <command>svnsync</command> obtenha a
+ resposta resultante do servidor do repositório de origem, ele
+ começa a repassar essas revisões para o servidor do repositório
+ de destino como novas operações de commit.</para>
<screen>
$ svnsync help synchronize
@@ -2758,44 +2765,49 @@
Copied properties for revision 23408.
</screen>
- <para>Of particular interest here is that for each mirrored
- revision, there is first a commit of that revision to the
- target repository, and then property changes follow. This is
- because the initial commit is performed by (and attributed to)
- the user <literal>syncuser</literal>, and datestamped with the
- time as of that revision's creation. Also, Subversion's
- underlying repository access interfaces don't provide a
- mechanism for setting arbitrary revision properties as part of
- a commit. So <command>svnsync</command> follows up with an
- immediate series of property modifications which copy all the
- revision properties found for that revision in the source
- repository into the target repository. This also has the
- effect of fixing the author and datestamp of the revision
- to match that of the source repository.</para>
-
- <para>Also noteworthy is that <command>svnsync</command>
- performs careful bookkeeping that allows it to be safely
- interrupted and restarted without ruining the integrity of the
- mirrored data. If a network glitch occurs while mirroring a
- repository, simply repeat the <command>svnsync
- synchronize</command> command and it will happily pick up
- right where it left off. In fact, as new revisions appear in
- the source repository, this is exactly what you to do
- in order to keep your mirror up-to-date.</para>
-
- <para>There is, however, one bit of inelegance in the process.
- Because Subversion revision properties can be changed at any
- time throughout the lifetime of the repository, and don't
- leave an audit trail that indicates when they were changed,
- replication processes have to pay special attention to them.
- If you've already mirrored the first 15 revisions of a
- repository and someone then changes a revision property on
- revision 12, <command>svnsync</command> won't know to go back
- and patch up its copy of revision 12. You'll need to tell it
- to do so manually by using (or with some additionally tooling
- around) the <command>svnsync copy-revprops</command>
- subcommand, which simply re-replicates all the revision
- properties for a particular revision.</para>
+ <para>Interessante notar aqui que para cada uma das revisões
+ espelhadas, há primeiro uma submissão da revisão para o
+ repositório de destino, seguida então por uma mudança de
+ propriedade. Isso se deve porque a operação de commit inicial
+ é executada pelo (e atribuída ao) usuário
+ <literal>syncuser</literal>, e fica datada com o horário da
+ criação da revisão. E também, as interfaces de suporte para
+ acesso a repositórios do Subversion não dispõem de um mecanismo
+ arbitrário para propriedades de revisão como parte de uma
+ operação de commit. Assim, o <command>svnsync</command>
+ prossegue com uma série imediata de modificações de propriedades
+ que copiam todas as propriedades de revisão encontradas para
+ aquela revisão no repositório de origem para o repositório de
+ destino. Isso também tem o efeito de corrigir o autor e o
+ registro de data da revisão que passam a corresponder com
+ àquelas do repositório de origem.</para>
+
+ <para>Algo que também deve-se notar é que o
+ <command>svnsync</command> realiza registros cuidadosos que lhe
+ permitem que possam ser interrompidos e reiniciados sem prejuízo
+ para a integridade dos dados espelhados. Se ocorrer um problema
+ com a conexão de rede enquanto um repositório estiver sendo
+ espelhado, simplesmente repita o comando <command>svnsync
+ synchronize</command> e ele irá continuar tranquilamente sua
+ operação exatamente de onde parou. De fato, também se ocorrerem
+ novas revisões no repositório de origem, isto também é
+ exatamente o que você vai fazer para manter seus dados
+ corretamente sincronizados.</para>
+
+ <para>Há, porém, uma certa deselegância no processo. Como as
+ propriedades de revisão do Subversion podem ser modificadas a
+ qualquer momento durante o ciclo de vida do repositório, e como
+ não deixam trilha de auditoria que indique quando foram
+ modificadas, o processo de replicação precisa ter atenção
+ especial a elas. Se você já tinha espelhado as primeiras 15
+ revisões de um repositório e alguém então modificou uma
+ propriedade de revisão da revisão 12, o
+ <command>svnsync</command> não vai saber retornar e adequar sua
+ cópia da revisão 12. Você vai precisar dizer a ele para fazer
+ isto manualmente usando (ou com algum ferramental a mais) o
+ subcomando <command>svnsync copy-revprops</command>, que
+ simplesmente re-aplica todas as propriedades de revisão para uma
+ revisão em particular.</para>
<screen>
$ svnsync help copy-revprops
@@ -2810,31 +2822,34 @@
$
</screen>
- <para>That's repository replication in a nutshell. You'll
- likely want some automation around such a process. For
- example, while our example was a pull-and-push setup, you
- might wish to have your primary repository push changes to one
- or more blessed mirrors as part of its post-commit and
- post-revprop-change hook implementations. This would enable
- the mirror to be up-to-date in as near to realtime as is
- likely possible.</para>
-
- <para>Also, while it isn't very commonplace to do so,
- <command>svnsync</command> does gracefully mirror repositories
- in which the user as whom it authenticates only has partial
- read access. It simply copies only the bits of the repository
- that it is permitted to see. Obviously such a mirror is not
- useful as a backup solution.</para>
-
- <para>As far as user interaction with repositories and mirrors
- goes, it <emphasis>is</emphasis> possible to have a single
- working copy that interacts with both, but you'll have to jump
- through some hoops to make it happen. First, you need to
- ensure that both the primary and mirror repositories have the
- same repository UUID (which is not the case by default). You
- can set the mirror repository's UUID by loading a dump file
- stub into it which contains the UUID of the primary
- repository, like so:</para>
+ <para>Esta é a replicação de repositórios em poucas palavras.
+ Você talvez desejasse um processo um pouco mais automatizado.
+ Por exemplo, ainda que nosso exemplo tenha sido uma configuração
+ do tipo lê-de-um-lado-e-escreve-de-outro, você poderia querer
+ que seu repositório primário submetesse suas modificações,
+ replicando-as direto para um ou mais espelhos confiáveis como
+ parte das implementações de seus scripts post-commit e
+ post-revprop-change. Isto poderia disponibilizar o espelho
+ atualizado quase que praticamente em tempo real.</para>
+
+ <para>Também, ainda que de certa forma não represente um lugar
+ comum, o <command>svnsync</command> consegue espelhar
+ graciosamente os repositórios nos quais o usuário com o qual se
+ autentica só possui acesso de leitura. Ele apenas copia os
+ bits do repositório aos quais tem permissão de ver. Obviamente
+ um espelho desse tipo não é tão útil como uma solução de
+ backup.</para>
+
+ <para>No que diz respeito à interação do usuário com os
+ repositórios e os espelhos, <emphasis>é</emphasis> possível ter
+ uma única cópia de trabalho que interaja com ambos, mas você vai
+ ter que mostrar habilidade e resolver algumas questões para
+ fazer isso. Primeiro, você precisa garantir que tanto o
+ repositório primário quanto o espelho tenham o mesmo UUID de
+ repositório (o que não é o que acontece por padrão). Você pode
+ configurar o UUID do repositório carregando uma parte arquivo de
+ despejo que contenha o UUID do repositório primário, algo
+ tipo:</para>
<screen>
$ cat - <<EOF | svnadmin load --force-uuid dest
@@ -2845,31 +2860,33 @@
$
</screen>
- <para>Now that the two repositories have the same UUID, you can
- use <command>svn switch --relocate</command> to point your
- working copy to whichever of the repositories you wish to
- operate against, a process which is described in <xref
- linkend="svn.ref.svn.c.switch" />. There is a possible danger
- here, though, in that if the primary and mirror repositories
- aren't in close synchronization, a working copy up-to-date
- with, and pointing to, the primary repository will, if
- relocated to point to an out-of-date mirror, become confused
- about the apparent sudden loss of revisions it fully expects
- to be present, and throws errors to that effect. If this
- occurs, you can relocate your working copy back to the primary
- repository and then either wait until the mirror repository is
- up-to-date, or backdate your working copy to a revision you
- know is present in the sync repository and then retry the
- relocation.</para>
-
- <para>Finally, be aware that the revision-based replication
- provided by <command>svnsync</command> is only
- that—replication of revisions. It does not include such
- things as the hook implementations, repository or server
- configuration data, uncommitted transactions, or information
- about user locks on repository paths. Only information
- carried by the Subversion repository dump file format is
- available for replication.</para>
+ <para>Agora que os dois repositórios possuem o mesmo UUID, você
+ pode usar um <command>svn switch --relocate</command> para
+ apontar sua cópia de trabalho para onde quer que estejam os
+ repositórios com que você quer trabalhar, um procedimento que é
+ descrito em <xref linkend="svn.ref.svn.c.switch" />. Porém, há
+ um grande risco em potencial, que é se os repositórios primário
+ e de espelho não estiverem adequadamente sincronizados, uma
+ cópia atualizada, e que aponte para o repositório primário irá,
+ se realozada para apontar para um espelho desatualizado, se
+ tornar confusa sobre a aparente perda de revisões que de fato
+ estão plenamente presentes, e lançará erros reportando isso. Se
+ isto ocorrer, você pode realocar sua cópia de trabalho de volta
+ para o repositório primário e então ou esperar que seu
+ repositório espelho esteja atualizado, ou retroceder sua cópia
+ de trabalho para uma revisão que você sabe estar presente no
+ repositório sincronizado e então tentar a realocação
+ novamente.</para>
+
+ <para>Por último, esteja ciente de que a replicação baseada em
+ revisões oferecida pelo <command>svnsync</command> não é nada
+ mais do que isso—replicação de revisões. Ela não inclui
+ coisas como implementações de scripts de hook, dados de
+ configuração de repositório ou de servidor, transações não
+ submetidas, ou informações sobre travas de usuário ou caminhos
+ de repositório. Apenas informações que são carregadas pelo
+ formato de arquivo de despejo do Subversion estão disponíveis
+ para replicação.</para>
</sect2>
More information about the svn-pt_br
mailing list