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

codesite-noreply at google.com codesite-noreply at google.com
Sat Mar 15 15:09:45 CDT 2008


Author: paulosoares
Date: Fri Mar 14 20:00:48 2008
New Revision: 34

Modified:
   trunk/book/ch03-advanced-topics.xml

Log:
Concluída a 1ª Revisão das seções:

- File Portability (id="svn.advanced.props.file-portability")
- File Content Type (id="svn.advanced.props.special.mime-type")

Modified: trunk/book/ch03-advanced-topics.xml
==============================================================================
--- trunk/book/ch03-advanced-topics.xml	(original)
+++ trunk/book/ch03-advanced-topics.xml	Fri Mar 14 20:00:48 2008
@@ -847,20 +847,20 @@
   <sect1 id="svn.advanced.props.file-portability">
     <title>Portabilidade de Arquivo</title>
 
-    <para>Felizmente para os usuários do Subversion que rotineiramente
-      se encontram em diferentes computadores com diferentes sistemas
+    <para>Felizmente, para os usuários do Subversion que rotineiramente
+      se encontram em diferentes computadores, com diferentes sistemas
       operacionais, o programa de linha de comando do Subversion comporta-se
-      quase que identicamente em todos os sistemas.  Se você sabe como usar
-      o <command>svn</command> em uma plataforma, você sabe como manuseá-lo
-      em qualquer lugar.</para>
+      quase que da mesma forma em todos os sistemas.  Se você sabe como usar
+      o <command>svn</command> em uma plataforma, você saberá como manuseá-lo
+      em qualquer outra.</para>
 
-    <para>Entretanto, o mesmo nem sempre é verdade em outras classes gerais
-      de software, ou nos atuais arquivos que você mantém no Subversion. Por
+    <para>Entretanto, o mesmo nem sempre é verdade em outras classes de software
+      em geral, ou nos atuais arquivos que você mantém no Subversion. Por
       exemplo, em uma máquina Windows, a definição de um <quote>arquivo de
       texto</quote> seria similar à usada em uma máquina Linux, porém
       com uma diferença chave—os caracteres usados para marcar
-      o fim das linhas destes arquivos.  Existem outras diferenças,
-      também.  As platformas Unix têm (e o Subversion suporta) links
+      o fim das linhas destes arquivos.  Existem outras diferenças
+      também.  As plataformas Unix têm (e o Subversion suporta) links
       simbólicos; Windows não.  As plataformas Unix usam as permissões do
       sistema de arquivos para determinar a executabilidade; Windows usa
       as extensões no nome do arquivo.</para>
@@ -870,7 +870,7 @@
       coisas, o melhor que podemos fazer é tentar ajudar a tornar sua vida
       mais simples quando você precisar trabalhar com seus arquivos e
       diretórios versionados em múltiplos computadores e sistemas operacionais.
-      Esta seção descreve alguns dos meios que o Subversion faz isto.</para>
+      Esta seção descreve alguns dos meios de como o Subversion faz isto.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.advanced.props.special.mime-type">
@@ -889,57 +889,57 @@
     
         <para>Vários programas nos sistemas operacionais mais modernos fazem
           suposições sobre o tipo e formato do conteúdo de um arquivo
-          pelo nome do arquivo, especificamente sua extensão de arquivo.
+          pelo nome do arquivo, especificamente por sua extensão.
           Por exemplo, arquivos cujos nomes terminam em
-          <filename>.txt</filename> são geralmente supostos ser legíveis
-          humanamente, passíveis de serem compreendidos por simples leitura,
+          <filename>.txt</filename> são, geralmente, supostos ser legíveis
+          por humanos, passíveis de serem compreendidos por simples leitura,
           em vez dos que requerem processamento complexo para os decifrar.
-          Arquivos cujos nomes terminam em <filename>.png</filename>, por
-          outro lado, são assumidos serem do tipo <emphasis>Portable Network
-          Graphics</emphasis>—não legível humanamente no todo, e
-          perceptível apenas quando interpretado pelo software que entende
-          o formato PNG e pode tornar a informação neste formato como uma
+          Por outro lado, arquivos cujos nomes terminam em <filename>
+          .png</filename> assume-se serem do tipo <emphasis>Portable Network
+          Graphics</emphasis>— que não são legíveis por humanos, sendo
+          perceptíveis apenas quando interpretados pelo software que entende
+          o formato PNG, e pode tornar a informação neste formato como uma
           imagem desenhada por linhas.</para>
 
         <para>Infelizmente, algumas destas extensões têm seus significados
           modificados ao longo do tempo.  Quando os computadores pessoais
-          apareceram pela primeira vez, um arquivo nomeado
-          <filename>README.DOC</filename> teria sido certamente um arquivo de
+          apareceram pela primeira vez, um arquivo chamado
+          <filename>README.DOC</filename> certamente era um arquivo de
           texto simples, como são hoje os arquivos <filename>.txt</filename>.
           Porém, no meio dos anos de 1990, você poderia apostar que um arquivo
-          com este nome não seria um arquivo de texto simples, mas sim um
+          com este nome não seria mais um arquivo de texto simples, mas sim um
           documento do Microsoft Word em um formato proprietário e humanamente
           ilegível. Mas esta mudança não ocorreu da noite para o dia—houve
           certamente um período de confusão para os usuário de computador sobre
           o que exatamente eles tinham em mãos quando viam um arquivo
           <filename>.DOC</filename>.
           <footnote>
-            <para>Você pensa que foi árduo?  Durante este mesmo período, o
+            <para>Você acha que foi complicado?  Durante este mesmo período, o
               WordPerfect também usou <filename>.DOC</filename> como extensão
-              escolhida para seu formato de arquivo proprietário!</para>
+              para seu formato de arquivo proprietário!</para>
           </footnote>
         </para>
 
         <para>A popularidade das redes de computadores lançou ainda mais
           dúvidas sobre o mapeamento entre um nome de arquivo e seu conteúdo.
-          Com informações sendo servidas através de redes e geradas
-          dinamicamente por scripts no servidor, não houve muitas vezes
-          arquivos reais por si só, e portanto, sem nome de arquivo. Os
-          servidores Web, por exemplo, precisavam de algum outro modo de dizer
-          aos navegadores que eles estavam baixando um arquivo, assim o navegador
+          Com informações sendo servidas através das redes e geradas
+          dinamicamente por scripts no servidor, freqüentemente, observava-se
+          arquivos não reais e, portanto, sem nome. Os servidores
+          Web, por exemplo, precisavam de algum outro modo para dizer aos 
+          navegadores que eles estavam baixando um arquivo, assim o navegador
           poderia fazer algo inteligente com esta informação, quer seja para
           exibir os dados usando um programa registrado para lidar com este
-          tipo de dados, ou para solicitar ao usário onde armazenar na máquina
-          cliente os dados baixados.</para>
+          tipo de dados, quer seja para solicitar ao usário onde armazenar
+          os dados baixados.</para>
 
         <para>Finalmente, um padrão surgiu para, entre outras coisas,
           descrever o conteúdo de um fluxo de dados.  Em 1996, a RFC2045
           foi publicada, a primeira de cinco RFC's descrevendo o MIME.
-          Esta descreve o conceito de tipos e subtipos de mídia, e
+          Esta RFC descreve o conceito de tipos e subtipos de mídia, e
           recomenda uma sintaxe para a representação destes tipos.  Hoje,
           os tipos de mídia MIME—ou <quote>tipos MIME</quote>—são
 		  usados quase que universalmente em todas as aplicações de e-mail,
-		  servidores Web, e outros softwares como o mecanismo de fato
+		  servidores Web e outros softwares como o mecanismo de fato
 		  para esclarecer a confusão do conteúdo de
 		  arquivo.</para>
 
@@ -947,28 +947,28 @@
     
       <para>Por exemplo, um dos benefícios que o Subversion tipicamente
         fornece é a fusão contextual, baseada nas linhas, das mudanças recebidas
-        do servidor durante uma atuaização em seu arquivo de trabalho.  Mas
-        para arquivos contendo dados não-textuais, extiste muitas vezes nenhum
-        conceito de uma <quote>linha</quote>.  Assim, para arquivos versionados
+        do servidor durante uma atualização em seu arquivo de trabalho.  Mas,
+        para arquivos contendo dados não-textuais, muitas vezes não existe o
+        conceito de <quote>linha</quote>.  Assim, para os arquivos versionados
         cuja propriedade <literal>svn:mime-type</literal> é definida com
         um tipo MIME não-textual (geralmente, algo que não inicie com
-        <literal>text/</literal>, embora existam exceções), o
-        Subversion não tenta executar fusões contextuais durante
-        as atualizações.  Em vez disso, toda vez que você tenha modificado localmente
-        um arquivo binário da cópia de trabalho que está também sendo atualizada, seu arquivo
-        é deixado intocado e o Subversion cria dois novos arquivos.  Um
-        arquivo tem uma extensão <filename>.oldrev</filename> e contém a
+        <literal>text/</literal>, embora existam exceções), o Subversion
+        não tenta executar fusões contextuais durante as atualizações.
+        Em vez disso, quando você modifica localmente um arquivo binário
+        em sua cópia de trabalho, na momento da atualização, seu 
+        arquivo não é mexido, pois o Subversion cria dois novos arquivos.  Um
+        deles tem a extensão <filename>.oldrev</filename> e contém a
         revisão BASE do arquivo.  O outro arquivo tem uma extensão
         <filename>.newrev</filename> e contém o conteúdo
         da revisão atualizada do arquivo.  Este comportamento
-        é realmente para a proteção do usuário contra tentativas falhas
-        ao executar fusões contextuais nos arquivos que simplesmente
+        serve de proteção ao usuário contra falhas na tentativa
+        de executar fusões contextuais nos arquivos que simplesmente
         não podem ser contextualmente fundidos.</para>
 
-      <para>Além disso, se a propriedade <literal>svn:mime-type</literal> está
-        definida, etão o módulo Apache do Subversion usará seu valor para
-        preencher o cabeçalho HTTP <literal>Content-type:</literal> quando
-        responder a solicitações GET.  Isto oferece ao seu navegador web uma
+      <para>Além disso, se a propriedade <literal>svn:mime-type</literal> 
+        estiver definida, então o módulo Apache do Subversion usará seu valor 
+        para preencher o cabeçalho HTTP <literal>Content-type:</literal> quando
+        responder a solicitações GET.  Isto oferece ao navegador web uma
         dica crucial sobre como exibir um arquivo quando você o utiliza para
         examinar o conteúdo de seu repositório Subversion.</para>
 




More information about the svn-pt_br mailing list