[svnbook commit] r1217 - trunk/src/es/book
gradha
svnbook-dev at red-bean.com
Wed Apr 20 12:47:12 CDT 2005
Author: gradha
Date: Wed Apr 20 12:47:11 2005
New Revision: 1217
Modified:
trunk/src/es/book/ch07.xml
Log:
Book Spanish. Translated 42 paragraphs.
Modified: trunk/src/es/book/ch07.xml
==============================================================================
--- trunk/src/es/book/ch07.xml (original)
+++ trunk/src/es/book/ch07.xml Wed Apr 20 12:47:11 2005
@@ -692,7 +692,7 @@
</listitem>
</varlistentry>
- <!-- ###TODO add description of other options shown in example
+ <!-- ###TODO add description of other options shown in example
registry file, e.g., log-encoding, etc. -->
</variablelist>
@@ -1617,126 +1617,139 @@
<sect3 id="svn-ch-7-sect-2.3.5">
<title><literal>svn:eol-style</literal></title>
- <para>Unless otherwise noted using a versioned file's
- <literal>svn:mime-type</literal> property, Subversion
- assumes the file contains human-readable data. Generally
- speaking, Subversion only uses this knowledge to determine
- if contextual difference reports for that file are
- possible. Otherwise, to Subversion, bytes are bytes.</para>
+ <para>Mientras la propiedad <literal>svn:mime-type</literal>
+ de un fichero versionado no indique lo contrario,
+ Subversion asume que el fichero contiene datos legibles
+ por seres humanos. En general, Subversion slo usa
+ este conocimiento para determinar si se pueden realizar
+ ficheros diferenciales contextuales sobre el fichero.
+ En caso contrario, para Subversion, los bytes son
+ bytes.</para>
- <para>This means that by default, Subversion doesn't pay any
- attention to the type of <firstterm>end-of-line (EOL)
- markers</firstterm> used in your files. Unfortunately,
- different operating system use different tokens to represent
- the end of a line of text in a file. For example, the usual
- line ending token used by software on the Windows platform
- is a pair of ASCII control characters—carriage return
- (<literal>CR</literal>) and line feed
- (<literal>LF</literal>). Unix software, however, just uses
- the <literal>LF</literal> character to denote the end of a
- line.</para>
-
- <para>Not all of the various tools on these operating systems
- are prepared to understand files that contain line endings
- in a format that differs from the <firstterm>native line
- ending style</firstterm> of the operating system on which
- they are running. Common results are that Unix programs
- treat the <literal>CR</literal> character present in Windows
- files as a regular character (usually rendered as
- <literal>^M</literal>), and that Windows programs combine
- all of the lines of a Unix file into one giant line because
- no carriage return-linefeed (or <literal>CRLF</literal>)
- character combination was found to denote the end of
- line.</para>
-
- <para>This sensitivity to foreign EOL markers can become
- frustrating for folks who share a file across different
- operating systems. For example, consider a source code
- file, and developers that edit this file on both Windows and
- Unix systems. If all the developers always use tools which
- preserve the line ending style of the file, no problems
- occur.</para>
-
- <para>But in practice, many common tools either fail to
- properly read a file with foreign EOL markers, or they
- convert the file's line endings to the native style when the
- file is saved. If the former is true for a developer, he
- has to use an external conversion utility (such as
- <command>dos2unix</command> or its companion,
- <command>unix2dos</command>) to prepare the file for
- editing. The latter case requires no extra preparation.
- But both cases result in a file that differs from the
- original quite literally on every line! Prior to committing
- his changes, the user has two choices. Either he can use a
- conversion utility to restore the modified file to the same
- line ending style that it was in before his edits were made.
- Or, he can simply commit the file—new EOL markers and
- all.</para>
-
- <para>The result of scenarios like these include wasted time
- and unnecessary modifications to committed files. Wasted
- time is painful enough. But when commits change every line
- in a file, this complicates the job of determining which of
- those lines were changed in a non-trivial way. Where was
- that bug really fixed? On what line was a syntax error
- introduced?</para>
-
- <para>The solution to this problem is the
- <literal>svn:eol-style</literal> property. When this
- property is set to a valid value, Subversion uses it to
- determine what special processing to perform on the file so
- that the file's line ending style isn't flip-flopping with
- every commit that comes from a different operating
- system. The valid values are:</para>
+ <para>Esto significa que por defecto, Subversion no
+ presta atencin al tipo de <firstterm>marcas de fn de
+ lnea (EOL)</firstterm> que use en sus ficheros.
+ Desafortunadamente, diferentes sistemas operativos
+ usan carcteres diferentes para representar los fines
+ de lnea en un fichero de texto. Por ejemplo, el carcter
+ de fín de línea habitual usado por software en la
+ plataforma Windows es una pareja de caracteres de
+ control ASCII —retorno de carro (<literal>CR</literal>)
+ y nueva línea<!-- TODO line feed mal traducido-->
+ (<literal>LF</literal>). En su lugar, el software
+ Unix usa simplemente el carácter <literal>LF</literal>
+ para indicar nueva línea.</para>
+
+ <para>No todas las herramientas en estos sistemas
+ operativos están preparadas para entender ficheros
+ en formatos que difieran del <firstterm>estilo de fín
+ de línea nativo</firstterm> del sistema operativo
+ sobre el cual están corriendo. Los resultados habituales
+ son que los programas Unix tratan el carácter
+ <literal>CR</literal> presente en ficheros Windows
+ como carácteres regulares (normalmente mostrados como
+ <literal>^M</literal>), y los programas Windows
+ combinan todas las líneas de un fichero Unix en una
+ línea gigante porque no encuentranla combinación de
+ retorno de carro y nueva línea (o <literal>CRLF</literal>)
+ que marca el fin de línea.</para>
+
+ <para>Esta sensitividad <!--TODO bonito palabro --> a marcas
+ EOL extrañas puede resultar frustrante para quienes
+ comparten un fichero en múltiples sistemas operativos
+ diferentes. Por ejemplo, considere un fichero de
+ código fuente y desarrolladores que modifiquen este
+ fichero tanto en Windows como en Unix. Si todos los
+ desarrolladores usan herramientas que preservan el
+ estilo de fin de línea del fichero, no ocurrirán
+ problemas.</para>
+
+ <para>Pero en la práctica, muchas herramientas comunes o
+ bien fallan al leer un fichero con marcas EOL extrañas,
+ o bien convierten los finales de línea al estilo
+ nativo cuando el fichero es guardado. Si lo primero
+ es cierto para un desarrollador, tendrá que usar una
+ utilidad de conversión externa (como por ejemplo
+ <command>dos2unix</command> o su compañera,
+ <command>unix2dos</command>) para preparar el fichero
+ antes de modificarlo. En el segundo caso no hace falta
+ preparación adicional. ¡Pero en ambos casos el resultado
+ es un fichero que difiere del origenal en todas y
+ cada una de las líneas! Antes de enviar sus cambios
+ al repositorio, el usuario tiene dos opciones. O bien
+ usa una utilidad de conversión para recuperar el
+ estilo de línea que tenía el fichero antes de ser
+ modificadi. O, simplemente puede enviar sus
+ cambios—con nuevas marcas EOL y todo.</para>
+
+ <para>El resultado de este tipo de escenarios incluyen
+ tiempo perdido en modificaciones innecesarias sobre
+ ficheros enviados al repositorio. Perder tiempo ya
+ es doloroso. Pero cuando un cambio modifica toda línea
+ del fichero, esto complica el trabajo de determinar
+ qué lineas realmente cambiaron de un modo poco trivial
+ <!-- TODO estilo, "no trivial"-->. ¿Fue el fallo
+ realmente corregido? ¿En qué línea se introdujo un
+ error de sintaxis?</para>
+
+ <para>La solución a este problema es la propiedad
+ <literal>svn:eol-style</literal>. Cuando se ajusta
+ esta propiedad a un valor válido, Subversion la usa
+ para determinar si tiene que realizar un proceso
+ especial sobre el fichero para que los finales de
+ línea del fichero no bailen como un flip-flop con
+ cada cambio enviado al repositorio proveniente de un
+ sistema operativo diferente. Los valores válidos
+ son:</para>
<variablelist>
<varlistentry>
<term><literal>native</literal></term>
<listitem>
- <para>This causes the file to contain the EOL markers
- that are native to the operating system on which
- Subversion was run. In other words, if a user on a
- Windows machine checks out a working copy that
- contains a file with an
- <literal>svn:eol-style</literal> property set to
- <literal>native</literal>, that file will contain
- <literal>CRLF</literal> EOL markers. A Unix user
- checking out a working copy which contains the same
- file will see <literal>LF</literal> EOL markers in his
- copy of the file.</para>
-
- <para>Note that Subversion will actually store the file
- in the repository using normalized
- <literal>LF</literal> EOL markers regardless of the
- operating system. This is basically transparent to
- the user, though.</para>
+ <para>Esto provoca que el fichero contenta marcas EOL
+ nativas del sistema operativo en que fue
+ ejecutado Subversion. En otras palabras.
+ si un usuario de Windows obtiene una copia local
+ de un fichero cuya propiedad
+ <literal>svn:eol-style</literal> contenga el valor
+ <literal>native</literal>, ese fichero contendrá
+ marcas EOL <literal>CRLF</literal>. Un usuario de
+ Unix que obtenga una copia local del mismo fichero
+ verá marcas EOL <literal>LF</literal>.</para>
+
+ <para>Tenga en cuenta que Subversion en realidad
+ almacenará el fichero en el repositorio usando
+ marcas EOL <literal>LF</literal> normalizadas
+ sin importar el sistema operativo. No obstante,
+ esto es básicamente transparente para el
+ usuario.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CRLF</literal></term>
<listitem>
- <para>This causes the file to contain
- <literal>CRLF</literal> sequences for EOL markers,
- regardless of the operating system in use.</para>
+ <para>Esto provoca que el fichero contenga la secuencia
+ <literal>CRLF</literal> como marcas EOL, sin importar
+ el sistema operativo usado.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>LF</literal></term>
<listitem>
- <para>This causes the file to contain
- <literal>LF</literal> characters for EOL markers,
- regardless of the operating system in use.</para>
+ <para>Esto provoca que el fichero contenga el carácter
+ <literal>LF</literal> como marca EOL, sin importar
+ el sistema operativo usado.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CR</literal></term>
<listitem>
- <para>This causes the file to contain
- <literal>CR</literal> characters for EOL markers,
- regardless of the operating system in use. This line
- ending style is not very common. It was used on older
- Macintosh platforms (on which Subversion doesn't even
- run).</para>
+ <para>Esto provoca que el fichero contenga el carácter
+ <literal>CR</literal> como marca EOL, sin importar
+ el sistema operativo usado. Este estilo de fín de
+ línea no es muy habitual. Fue usado en plataformas
+ Macintosh antiguas (en las cuales Subversion ni si
+ quiera funciona).</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1746,66 +1759,75 @@
<sect3 id="svn-ch-7-sect-2.3.6">
<title><literal>svn:externals</literal></title>
- <para>The <literal>svn:externals</literal> property contains
- instructions for Subversion to populate a versioned
- directory with one or more other checked-out Subversion
- working copies. For more information on this keyword and
- its use, see <xref linkend="svn-ch-7-sect-3"/>.</para>
+ <para>La propiedad <literal>svn:externals</literal> contiene
+ instrucciones para Subversion de poblar el directorio
+ con una o más copias locales de trabajo de Subversion.
+ Para más información sobre esta propiedad y sus usos,
+ vea <xref linkend="svn-ch-7-sect-3"/>.</para>
</sect3>
</sect2>
<!-- ***************************************************************** -->
<sect2 id="svn-ch-7-sect-2.4">
- <title>Automatic Property Setting</title>
+ <title>Ajuste automático de propiedades</title>
- <para>Properties are a powerful feature of Subversion, acting as
- key components of many Subversion features discussed elsewhere
- in this and other chapters—textual diff and merge
- support, keyword substitution, newline translation, etc. But
- to get the full benefit of properties, they must be set on the
- right files and directories. Unfortunately, that can be a
- step easily forgotten in the routine of things, especially
- since failing to set a property doesn't usually result in an
- obvious error condition (at least compared to, say, failing to
- add a file to version control). To help your properties get
- applied to the places that need them, Subversion provides a
- couple of simple but useful features.</para>
-
- <para>Whenever you introduce a file to version control using the
- <command>svn add</command> or <command>svn import</command>
- commands, Subversion runs a very basic heuristic to determine
- if that file consists of human-readable or non-human-readable
- content. If the latter is the decision made, Subversion will
- automatically set the <literal>svn:mime-type</literal>
- property on that file to
- <literal>application/octet-stream</literal> (the generic
- <quote>this is a collection of bytes</quote> MIME type). Of
- course, if Subversion guesses incorrectly, or if you wish to
- set the <literal>svn:mime-type</literal> property to something
- more precise—perhaps <literal>image/png</literal> or
- <literal>application/x-shockwave-flash</literal>—you can
- always remove or edit that property.</para>
-
- <para>Subversion also provides the auto-props feature, which
- allows you to create mappings of filename patterns to property
- names and values. These mappings are made in your runtime
- configuration area. They again affect adds and imports, and
- not only can override any default MIME type decision made by
- Subversion during those operations, they can also set
- additional Subversion or custom properties, too. For example,
- you might create a mapping that says that any time you add
- JPEG files—ones that match the pattern
- <literal>*.jpg</literal>—Subversion should automatically
- set the <literal>svn:mime-type</literal> property on those
- files to <literal>image/jpeg</literal>. Or perhaps any files
- that match <literal>*.cpp</literal> should have
- <literal>svn:eol-style</literal> set to
- <literal>native</literal>, and <literal>svn:keywords</literal>
- set to <literal>Id</literal>. Auto-prop support is perhaps
- the handiest property related tool in the Subversion toolbox.
- See <xref linkend="svn-ch-7-sect-1.3.2"/> for more about
- configuring that support.</para>
+ <para>Las propiedades son una poderosa característica de
+ Subversion, actuando como componentes clave de muchas
+ características de Subversion descritas en este y otros
+ capítulos—soporte de diferenciado de ficheros y
+ fusión textual, sustitución de palabras clave, traducción
+ de fines de línea, etc. Pero para obtener por completo
+ sus beneficios, debe ajustarlas en los ficheros y
+ directorios adecuados. Desafortunadamente, este paso
+ puede ser fácilmente olvidado en la rutina, especialmente
+ dado que olvidar ajustar una propiedad normalmente no
+ se traduce en una condición de error obvia (al menos
+ si la compara, con digamos, olvidar añadir un fichero
+ al repositorio). Para ayudar a sus propiedades a que
+ sean aplicadas en los lugares necesarios, Subversion
+ proporciona un par de características simples pero
+ útiles.</para>
+
+ <para>Siempre que pone un fichero bajo control de revisiones
+ usando los comandos <command>svn add</command> o
+ <command>svn import</command>, Subversion ejecuta una
+ heurística básica para determinar si el fichero se
+ compone de contenido legible o no legible por un ser
+ humano. Si decide lo último, Subversion ajustará
+ automáticamente la propiedad <literal>svn:mime-type</literal>
+ de ese fichero a <literal>application/octet-stream</literal>
+ (el tipo MIME genérico <quote>esto es un grupo de
+ bytes</quote>). Por supuesto, si Subversion no acierta,
+ puede ajustar la propiedad <literal>svn:mime-type</literal>
+ a otro valor más concreto—quizás
+ <literal>image/png</literal> o
+ <literal>application/x-shockwave-flash</literal>—siempre
+ puede eliminar o modificar esta propiedad.</para>
+
+ <para>Subversion también proporciona la característica de
+ auto propiedades, las cuales le permiten crear una
+ relación de patrones de ficheros a nombres y valores
+ de propiedades. Estas relaciones son creadas en su
+ área de parámetros de ejecución. De nuevo, éstos afectan
+ a adiciones e importaciones, y no sólo pueden sobreescribir
+ cualquier tipo de decisión MIME por defecto tomada por
+ Subversion, también pueden ajustar otras propiedadesç
+ propias o de Subversion. Por ejemplo, podría crear una
+ relación que dice que cada vez que añada ficheros
+ JPEG—aquellos que coincidan con el patrón
+ <literal>*.jpg</literal>—Subversion debería ajustar
+ automáticamente la propiedad <literal>svn:mime-type</literal>
+ de esos ficheros a <literal>image/jpeg</literal>. O
+ quizás cualquier fichero que concida con
+ <literal>*.cpp</literal> debería tener la propiedad
+ <literal>svn:eol-style</literal> ajustada a
+ <literal>native</literal>, y <literal>svn:keywords</literal>
+ ajustada a <literal>Id</literal>. El soporte de
+ propiedades automáticas es quizás la herramienta de
+ Subversion más útil en cuanto a propiedades. Vea <xref
+ linkend="svn-ch-7-sect-1.3.2"/> para más información
+ sobre cómo configurar esta característica.</para>
</sect2>
</sect1>
@@ -1814,33 +1836,33 @@
<!-- *** SECTION 3: EXTERNALS DEFINITIONS *** -->
<!-- ******************************************************************* -->
<sect1 id="svn-ch-7-sect-3">
- <title>Externals Definitions</title>
+ <title>Repositorios externos</title>
+
+ <para>A veces resulta útil construír una copia de trabajo local
+ compuesta a partir de varias. Por ejemplo, podría querer que
+ diferentes subdirectorios provengan de repositorios completamente
+ diferentes. Decididamente puede configurar tal escenario a
+ mano—usando <command>svn checkout</command> para crear
+ una copia local con la estructura anidada que intenta alcanzar.
+ Pero si esta estructura es importante para cualquiera que use
+ el repositorio, cualquier otro usuario necesitará realizar
+ las mismas operaciones de obtención de copias locales que
+ usted hizo.</para>
+
+ <para>Afortunadamente, Subversion proporciona soporte de
+ <firstterm>definiciones externas</firstterm>. Una definición
+ externa es la relación de un directorio local con la URL—y
+ posiblemente una revisión particular—de un recurso
+ versionado. En Subversion, declara definiciones externas en
+ grupos usando la propiedad <literal>svn:externals</literal>.
+ Puede crear o midifcar esta propiedad usando los comandos
+ <command>svn propset</command> o <command>svn propedit</command>
+ (vea <xref linkend="svn-ch-7-sect-2.1"/>). Puede ser ajustada
+ en un directorio versionado, y su valor es una tabla multi
+ línea de subdirectorios (relativos al directorio versionado
+ sobre el cual se pone la propiedad) y URLs de repositorios
+ Subversion absolutas, completamente cualificadas.</para>
- <para>Sometimes it is useful to construct a working copy that is
- made out of a number of different checkouts. For example, you
- may want different subdirectories to come from different
- locations in a repository, or perhaps from different
- repositories altogether. You could certainly setup such a
- scenario by hand—using <command>svn checkout</command> to
- create the sort of nested working copy structure you are trying
- to achieve. But if this layout is important for everyone who
- uses your repository, every other user will need to perform the
- same checkout operations that you did.</para>
-
- <para>Fortunately, Subversion provides support for
- <firstterm>externals definitions</firstterm>. An externals
- definition is a mapping of a local directory to the
- URL—and possibly a particular revision—of a
- versioned resource. In Subversion, you declare externals
- definitions in groups using the <literal>svn:externals</literal>
- property. You can create or modify this property using
- <command>svn propset</command> or <command>svn
- propedit</command> (see <xref linkend="svn-ch-7-sect-2.1"/>).
- It can be set on any versioned directory,
- and its value is a multi-line table of subdirectories (relative
- to the versioned directory on which the property is set) and
- fully qualified, absolute Subversion repository URLs.</para>
-
<screen>
$ svn propget svn:externals calc
third-party/sounds http://sounds.red-bean.com/repos
@@ -1848,19 +1870,21 @@
third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker
</screen>
- <para>The convenience of the <literal>svn:externals</literal>
- property is that once it is set on a versioned directory,
- everyone who checks out a working copy with that directory also
- gets the benefit of the externals definition. In other words,
- once one person has made the effort to define those nested
- working copy checkouts, no one else has to
- bother—Subversion will, upon checkout of the original
- working copy, also checkout the external working copies.</para>
-
- <para>Note the previous externals definition example. When
- someone checks out a working copy of the
- <filename>calc</filename> directory, Subversion also continues
- to checkout the items found in its externals definition.</para>
+ <para>La convenciencia de la propiedad <literal>svn:externals</literal>
+ es que una vez ha sido ajustada en un directorio versionado,
+ cualquiera que obtenga una copia local de trabajo de ese
+ directorio, también obtendrá el beneficio de la definición
+ externa. En otras palabras, una vez que una persona ha realizado
+ el esfuerzo de definir esa estructura anidada de direcciones
+ de repositorios, nadie más tiene que volver a repetirlo—ya
+ que Subversion, a la hora de obtener una copia local, también
+ obtendrá una copia de los repositorios externos.</para>
+
+ <para>Fíjese en la definición externa del ejemplo anterior.
+ Cuando alguien obtenga la copia local del directorio
+ <filename>calc</filename>, Subversion continuará obteniendo
+ copias locales de los elementos indicados por las definiciones
+ externas.</para>
<screen>
$ svn checkout http://svn.example.com/repos/calc
@@ -1883,51 +1907,53 @@
…
</screen>
- <para>If you need to change the externals definition, you can do
- so using the regular property modification subcommands. When
- you commit a change to the <literal>svn:externals</literal>
- property, Subversion will synchronize the checked-out items
- against the changed externals definition when you next run
- <command>svn update</command>. The same thing will happen when
- others update their working copies and receive your changes to
- the externals definition.</para>
-
- <para>The <command>svn status</command> command also recognizes
- externals definitions, displaying a status code of
- <literal>X</literal> for the disjoint subdirectories into which
- externals are checked out, and then recursing into those
- subdirectories to display the status of the external items
- themselves.</para>
-
- <para>The support that exists for externals definitions in
- Subversion today can be a little misleading, though. The
- working copies created via the externals definition support are
- still disconnected from the primary working copy (on whose
- versioned directories the <literal>svn:externals</literal>
- property was actually set). And Subversion still only truly
- operates on non-disjoint working copies. So, for example, if
- you want to commit changes that you've made in one or more of
- those external working copies, you must run <command>svn
- commit</command> explicitly on those working
- copies—committing on the primary working copy will not
- recurse into any external ones.</para>
-
- <para>Also, since the definitions themselves use absolute URLs,
- moving or copying a directory to which they are attached will
- not affect what gets checked out as an external (though the
- relative local target subdirectory will, of course, move with
- renamed directory). This can be confusing—even
- frustrating—in certain situations. For example, if you
- use externals definitions on a directory in your
- <filename>/trunk</filename> development line which point to
- other areas of that same line, and then you use <command>svn
- copy</command> to branch that line to some new location
- <filename>/branches/my-branch</filename>, the externals
- definitions on items in your new branch will still refer to
- versioned resources in <filename>/trunk</filename>. Also, be
- aware that if you need to re-parent your working copy (using
- <command>svn switch --relocate</command>), externals definitions
- will <emphasis>not</emphasis> also be re-parented.</para>
+ <para>Si necesita cambiar las definiciones externas, puede
+ hacerlo usando los subcomandos habituales de modificación de
+ propiedades. Cuando envíe un cambio al repositorio de la
+ propiedad <literal>svn:externals</literal>, Subversion
+ sincronizará las copias locales obtenidas contra las definiciones
+ externas la siguiente vez que ejecute <command>svn update</command>.
+ Lo mismo ocurrirá cuando otras personas actualicen sus copias
+ locales y obtengan sus cambios sobre las definiciones
+ externas.</para>
+
+ <para>El comando <command>svn status</command> también reconoce
+ definiciones externas, mostrando el código de estado
+ <literal>X</literal> para los subdirectorios disjuntos en los
+ cuales se almacenarán las copias locales, entrando después
+ de manera recursiva en estos directorios para mostrar el
+ estado de los propios elementos externos.</para>
+
+ <para>No obstante, el soporte de definiciones externas que hay
+ hoy en Subversion puede ser ligeramente engañoso. Las copias
+ locales creadas vía definición externa todavía están desconectadas
+ de la copia local de trabajo primaria (en cuyos directorios
+ versionados ajustó la propiedad <literal>svn:externals</literal>).
+ Y Subversion todavía funciona sólamente sobre copias locales
+ no disjuntas. Así que, por ejemplo, si quiere enviar cambios
+ al repositorio realizados en una o más de esas copias locales
+ externas, debe ejecutar el comando <command>svn commit</command>
+ de forma explícita en esas copias locales—enviar los
+ cambios de la copia local de trabajo primaria no recurrirá
+ en las copias externas.</para>
+
+ <para>Además, dado que las propias definiciones son URLs
+ absolutas, mover o copiar el directorio sobre el cual están
+ fijadas no afectará a aquello que se obtiene como copia externa
+ (aunque, claro está, el directorio local relativo indicado
+ será movido con el directorio renombrado). Esto puede ser
+ confuso—incluso frustrante—en ciertas situaciones.
+ Por ejemplo, si usa la definición externa sobre un directorio
+ en su línea de desarrollo principal (<filename>/trunk</filename>)
+ apuntando a otras áreas de la misma línea, y entonces usa
+ <command>svn copy</command> para crear una rama de esa línea
+ en <filename>/branches/my-branch</filename>, la definición
+ externa sobre los elementos en su nueva rama todavía se
+ referirán a los recursos versionados en <filename>/trunk</filename>.
+ Además, tenga en cuenta que si necesita relocalizar su copia
+ local de trabajo (usando <command>svn switch --relocate</command>),
+ las definiciones externas <emphasis>no</emphasis> serán
+ relocalizadas.</para>
</sect1>
@@ -1935,110 +1961,125 @@
<!-- *** SECTION 4: VENDOR BRANCHES *** -->
<!-- ******************************************************************* -->
<sect1 id="svn-ch-7-sect-4">
- <title>Vendor branches</title>
-
- <para>As is especially the case when developing software, the data
- that you maintain under version control is often closely related
- to, or perhaps dependent upon, someone else's data. Generally,
- the needs of your project will dictate that you stay as
- up-to-date as possible with the data provided by that external
- entity without sacrificing the stability of your own project.
- This scenario plays itself out all the time—anywhere that
- the information generated by one group of people has a direct
- effect on that which is generated by another group.</para>
-
- <para>For example, software developers might be working on an
- application which makes use of a third-party library.
- Subversion has just such a relationship with the Apache Portable
- Runtime library (see <xref linkend="svn-ch-8-sect-2.1" />). The
- Subversion source code depends on the APR library for all its
- portability needs. In earlier stages of Subversion's
- development, the project closely tracked APR's changing API,
- always sticking to the <quote>bleeding edge</quote> of the
- library's code churn. Now that both APR and Subversion have
- matured, Subversion attempts to synchronize with APR's library
- API only at well-tested, stable release points.</para>
-
- <para>Now, if your project depends on someone else's information,
- there are several ways that you could attempt to synchronize that
- information with your own. Most painfully, you could issue oral
- or written instructions to all the contributors of your project,
- telling them to make sure that they have the specific versions
- of that third-party information that your project needs. If the
- third-party information is maintained in a Subversion
- repository, you could also use Subversion's externals
- definitions to effectively <quote>pin down</quote> specific
- versions of that information to some location in your own
- working copy directory (see <xref linkend="svn-ch-7-sect-3" />).</para>
-
- <para>But sometimes you want to maintain custom modifications to
- third-party data in your own version control system. Returning
- to the software development example, programmers might need to
- make modifications to that third-party library for their own
- purposes. These modifications might include new functionality
- or bug fixes, maintained internally only until they become part
- of an official release of the third-party library. Or the
- changes might never be relayed back to the library maintainers,
- existing solely as custom tweaks to make the library further
- suit the needs of the software developers.</para>
-
- <para>Now you face an interesting situation. Your project could
- house its custom modifications to the third-party data in some
- disjointed fashion, such as using patch files or full-fledged
- alternate versions of files and directories. But these quickly
- become maintenance headaches, requiring some mechanism by which
- to apply your custom changes to the third-party data, and
- necessitating regeneration of those changes with each successive
- version of the third-party data that you track.</para>
-
- <para>The solution to this problem is to use <firstterm>vendor
- branches</firstterm>. A vendor branch is a directory tree in
- your own version control system that contains information
- provided by a third-party entity, or vendor. Each version of
- the vendor's data that you decide to absorb into your project is
- called a <firstterm>vendor drop</firstterm>.</para>
-
- <para>Vendor branches provide two key benefits. First, by storing
- the currently supported vendor drop in your own version control
- system, the members of your project never need to question
- whether they have the right version of the vendor's data. They
- simply receive that correct version as part of their regular
- working copy updates. Secondly, because the data lives in your
- own Subversion repository, you can store your custom changes to
- it in-place—you have no more need of an automated (or
- worse, manual) method for swapping in your customizations.</para>
+ <title>Ramas de proveedores</title>
+ <para>En el caso especial del desarrollo de software, los datos
+ que mantiene bajo control de versiones están a menudo
+ relacionados con, o quizás dependan de, los datos de terceros.
+ Generalmente, las necesidades de su proyecto dictarán que
+ debe permanecer lo más actualizado posible con los datos
+ proporcionados por esa entidad externa sin sacrificar la
+ estabilidad de su propio proyecto. Este escenario ocurre
+ constantemente—siempre que la información generada por
+ un grupo de personas tiene un efecto directo en aquello
+ generado por otro grupo.</para>
+
+ <para>Por ejemplo, desarrolladores de software podrían estar
+ trabajando en una aplicación que hace uso de una librería
+ externa. Subversion tiene justamente este tipo de relación
+ con la Apache Portable Runtime library <!-- TODO traducción
+ de APR? --> (vea <xref linkend="svn-ch-8-sect-2.1" />). El
+ código fuente de Subversion depende de la librería APR para
+ sus necesidades de portabilidad. En fases iniciales del
+ desarrollo de Subversion, el proyecto seguía de cerca los
+ cambios de la API de la APR, siempre manteniéndose en <!--TODO
+ buscar bleeding edge, me suena que hay discusión de esto -->
+ la <quote>última versión</quote> recién salida del horno.
+ Ahora que tanto APR como Subversion han madurado, Subversion
+ sólo intenta sincronizarse con la API de APR en momentos bien
+ verificados, versiones estables públicas.</para>
+
+ <para>Ahora, si su proyecto depende de la información de otros,
+ hay varios modos que podría intentar para sincronizar esa
+ información con la suya. La más dolorosa, sería ordenar
+ verbalmente, o por escrito, instrucciones a todos los
+ contribuyentes de su proyecto, indicándoles que se aseguren
+ de tener las versiones específicas de esa información externa
+ que su proyecto necesita. Si la información externa se
+ mantiene en un repositorio Subversion, podría usar las
+ definiciones externas de Subversion para <quote>fijar</quote>
+ de forma efectiva versiones específicas de esa información
+ en alguno de los directorios de su copia local (vea <xref
+ linkend="svn-ch-7-sect-3" />).</para>
+
+ <para>Pero a veces necesita mantener modificaciones propias a
+ los datos de terceros en su propio sistema de control de
+ versiones. Volviendo al ejemplo de desarrollo de software,
+ los programadores podrían necesitar hacer modificaciones a
+ esa librería exxterna para sus propios propósitos. Estas
+ modificaciones podrían incluir nueva funcionalidad o correcciones
+ de fallos, mantenidos internamente sólo hasta que se conviertan
+ en parte de un lanzamiento oficial de esa librería externa.
+ O los cambios quizás nunca sean enviados a los autores de la
+ librería, y existen solamente con el propósito de satisfacer
+ las necesidades de sus desarrolladores como modificaciones
+ personalizadas.</para>
+
+ <para>Ahora se encuentra en una situación interesante. Su
+ proyecto podría almacenar sus modificaciones propias a los
+ datos de terceros de algún modo disjunto, como usando ficheros
+ parche o completas versiones alternativas de ficheros y
+ directorios. Pero estos métodos se convierten rápidamente
+ en problemas de mantenimiento, requiriendo de algún mecanismo
+ que aplique sus cambios personales a los datos de terceros,
+ sin olvidar la necesidad de regenerar esos cambios con cada
+ versión sucesiva de los datos de terceros a los que sigue la
+ pista.</para>
+
+ <para>La solución a este problema es usar <firstterm>ramas de
+ proveedor</firstterm>. Una rama de proveedor es un árbol de
+ directorios en su propio sistema de control de versiones que
+ contiene información proporcionada por una entidad externa,
+ o proveedor. Cada versión de los datos del proveedor que
+ decide absorber en su proyecto es llamada <firstterm>hito de
+ proveedor</firstterm>.</para> <!-- TODO hito del proveedor
+ != vendor drop. Buscar algo mejor. -->
+
+ <para>Las ramas de proveedor proporcionan dos beneficios clave.
+ Primero, al almacenar el hito de proveedor actualmente soportado
+ en su propio sistema de control de versiones, los miembros
+ de su proyecto nunca tendrán que preguntarse si poseen la
+ versión correcta de los datos del proveedor. Simplemente
+ obtienen la versión correcta como parte de su actualización
+ habitual de sus copias locales de trabajo. Segundo, ya que
+ los datos viven en su propio repositorio Subversion, puede
+ almacenar cambios personalizados directamente en el mismo
+ lugar—ya no tiene necesidad de crear un método automático
+ (o peor aún, manual) para proporcionar sus modificaciones.</para>
+
<!-- ***************************************************************** -->
<sect2 id="svn-ch-7-sect-4.1">
- <title>General Vendor Branch Management Procedure</title>
-
- <para>Managing vendor branches generally works like this. You
- create a top-level directory (such as
- <filename>/vendor</filename>) to hold the vendor branches.
- Then you import the third party code into a subdirectory of
- that top-level directory. You then copy that subdirectory
- into your main development branch (for example,
- <filename>/trunk</filename>) at the appropriate location. You
- always make your local changes in the main development branch.
- With each new release of the code you are tracking you bring
- it into the vendor branch and merge the changes into
- <filename>/trunk</filename>, resolving whatever conflicts
- occur between your local changes and the upstream
- changes.</para>
-
- <para>Perhaps an example will help to clarify this algorithm.
- We'll use a scenario where your development team is creating a
- calculator program that links against a third-party complex
- number arithmetic library, libcomplex. We'll begin with the
- initial creation of the vendor branch, and the import of the
- first vendor drop. We'll call our vendor branch directory
- <filename>libcomplex</filename>, and our code drops will go
- into a subdirectory of our vendor branch called
- <filename>current</filename>. And since <command>svn
- import</command> creates all the intermediate parent
- directories it needs, we can actually accomplish both of these
- steps with a single command.</para>
+ <title>Procedimiento general de gestión de ramas de proveedor</title>
+ <para>Gestionar ramas de vendedor generalmente funciona de
+ esta manera. Primero crea un directorio en la raíz de
+ su jerarquía (como por ejemplo <filename>/vendor</filename>)
+ para almacenar las ramas de proveedor. Entonces importa
+ el código de terceros en un subdirectorio de ese diretorio
+ principal. Luego copia ese subdirectorio en su rama
+ principal de desarrollo (por ejemplo,
+ <filename>/trunk</filename>) en un lugar apropiado.
+ Siempre realiza cambios locales en la rama de desarrollo
+ principal. Con cada nueva versión del código que está
+ siguiendo, lo incluye en la rama de proveedor y fusiona
+ los cambios en <filename>/trunk</filename>, resolviendo
+ cualquier conflicto entre sus cambios locales y los
+ cambios oficiales.</para>
+
+ <para>Quizás un ejemplo ayude a aclarar este algoritmo.
+ Usaremos un escenario donde su equipo de desarrollo
+ está creando un programa calculador que enlaza contra
+ una librería externa de aritmética de números complejos,
+ libcomplex. Comenzaremos con la creación inicial de
+ la rama de proveedor, y la importación del primer hito
+ de proveedor. Llamaremos al directorio de nuestra rama
+ de proveedor <filename>libcomplex</filename>, y nuestros
+ hitos de código irán en un subdirectorio de nuestra
+ rama de proveedor llamado <filename>current</filename>.
+ Y dado que <command>svn import</command> crea todos los
+ directorios padre intermedios que necesita, en realidad
+ podemos realizar ambos pasos con un único comando.</para>
+
<screen>
$ svn import /path/to/libcomplex-1.0 \
http://svn.example.com/repos/vendor/libcomplex/current \
@@ -2046,16 +2087,17 @@
…
</screen>
- <para>We now have the current version of the libcomplex source
- code in <filename>/vendor/libcomplex/current</filename>. Now,
- we tag that version (see <xref linkend="svn-ch-4-sect-6" />)
- and then copy it into the main development branch. Our copy
- will create a new directory called
- <filename>libcomplex</filename> in our existing
- <filename>calc</filename> project directory. It is in this
- copied version of the vendor data that we will make our
- customizations.</para>
-
+ <para>Tenemos ahorala versión actual del código fuente de
+ libcomplex en <filename>/vendor/libcomplex/current</filename>.
+ Ahora, etiquetamos esa versión (vea <xref
+ linkend="svn-ch-4-sect-6" />) y luego la copiamos en
+ la rama principal de desarrollo. Nuestra copia creará
+ un nuevo directorio llamado <filename>libcomplex</filename>
+ en nuestro directorio existente de proyecto
+ <filename>calc</filename>. Es en esta versión copiada
+ de los datos del proveedor que realizaremos nuestras
+ personalizaciones.</para>
+
<screen>
$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \
http://svn.example.com/repos/vendor/libcomplex/1.0 \
@@ -2067,61 +2109,71 @@
…
</screen>
- <para>We check out our project's main branch—which now
- includes a copy of the first vendor drop—and we get to
- work customizing the libcomplex code. Before we know it, our
- modified version of libcomplex is now completely integrated
- into our calculator program.
+ <para>Ahora obtenemos una copia local de la rama principal
+ de nuestro proyecto—que ahora incluye una copia
+ del primer hito de proveedor—y comenzamos a
+ personalizar el código de libcomplex. Antes de darnos
+ cuenta, nuestra versión modificada de libcomplex está
+ completamente integrada en nuestro programa calculador.
<footnote>
- <para>And entirely bug-free, of course!</para>
+ <para>¡Y por su puesto, completamente libre de fallos!</para>
</footnote>
</para>
- <para>A few weeks later, the developers of libcomplex release a
- new version of their library—version 1.1—which
- contains some features and functionality that we really want.
- We'd like to upgrade to this new version, but without losing
- the customizations we made to the existing version. What we
- essentially would like to do is to replace our current
- baseline version of libcomplex 1.0 with a copy of libcomplex
- 1.1, and then re-apply the custom modifications we previously
- made to that library to the new version. But we actually
- approach the problem from the other direction, applying the
- changes made to libcomplex between versions 1.0 and 1.1 to our
- modified copy of it.</para>
+ <para>Unas pocas semanas después, los desarrolladores de
+ libcomplex lanzan una nueva versión de su librería—la
+ versión 1.1—la cual contiene algunas características
+ y funcionalidades que realmente deseamos. Nos gustaría
+ actualizarnos a esta nueva versión, pero sin perder las
+ personalizaciones que realizamos sobre la versión
+ anterior. Lo que esencialmente nos gustaría hacer, es
+ reemplazar nuestra versión de línea base de libcomplex
+ 1.0 con una copia de libcomplex 1.1, y entonces reaplicar
+ las modificaciones propias que anteriormente hicimos
+ sobre la librería antes de la nueva versión. Pero en
+ realidad nos acercaremos al problema desde otra dirección,
+ aplicando los cambios realizados sobre libcomplex entre
+ las versiones 1.0 y 1.1 sobre nuestra propia copia
+ modificada.</para>
+
+ <para>Para realizar esta actualización, obtenemos una copia
+ local de nuestra rama de proveedor, y reemplazamos el
+ código del directorio <filename>current</filename> con
+ el nuevo código fuente de libcomplex 1.1. Literalmente
+ copiamos nuevos ficheros sobre los existentes, quizás
+ expandiendo el fichero comprimido del distribución de
+ libcomplex 1.1 sobre nuestros ficheros y directorios.
+ El objetivo aquí es que el directorio
+ <filename>current</filename> solamente contenta el
+ código de libcomplex 1.1, y asegurarnos que todo ese
+ código fuente está bajo control de versiones. Oh, y
+ queremos realizar esto con la menor perturbación posible
+ sobre el historial del control de versiones.</para>
+
+ <para>Tras reemplazar el código de la versión 1.0 con el de
+ la 1.1, <command>svn status</command> mostrará los
+ ficheros con modificaciones locales, junto con quizás
+ algunos ficheros no versionados o ausentes. Si realizamos
+ lo que debíamos realizar, los ficheros no versionados
+ son aquellos ficheros nuevos introducidos en la versión
+ 1.1 de libcomplex—ejecutamos <command>svn
+ add</command> sobre ellos para ponerlos bajo control
+ de versiones. Los ficheros ausentes son ficheros que
+ existían en la 1.0 pero no en la 1.1, y sobre éstos
+ usamos <command>svn remove</command>. Finalmente, una
+ vezz que nuestra copia local de <filename>current</filename>
+ contiene únicamente el código de libcomplex 1.1, enviamos
+ al repositorio los cambios realizados para que tenga
+ este aspecto.</para>
+
+ <para>Nuestra rama <filename>current</filename> ahora contiene
+ el hito de proveedor. Etiquetamos la nueva versión
+ (del mismo modo que etiquetamos el anterior hito de
+ proveedor como la versión 1.0), y entonces fusionamos
+ las diferencias entre las etiquetas de la versión
+ anterior y la actual en nuestra rama principal de
+ desarrollo.</para>
- <para>To perform this upgrade, we checkout a copy of our vendor
- branch, and replace the code in the
- <filename>current</filename> directory with the new libcomplex
- 1.1 source code. We quite literally copy new files on top of
- existing files, perhaps exploding the libcomplex 1.1 release
- tarball atop our existing files and directories. The goal
- here is to make our <filename>current</filename> directory
- contain only the libcomplex 1.1 code, and to ensure that all
- that code is under version control. Oh, and we want to do
- this with as little version control history disturbance as
- possible.</para>
-
- <para>After replacing the 1.0 code with 1.1 code, <command>svn
- status</command> will show files with local modifications as
- well as, perhaps, some unversioned or missing files. If we
- did what we were supposed to do, the unversioned files are
- only those new files introduced in the 1.1 release of
- libcomplex—we run <command>svn add</command> on those to
- get them under version control. The missing files are files
- that were in 1.0 but not in 1.1, and on those paths we run
- <command>svn remove</command>. Finally, once our
- <filename>current</filename> working copy contains only the
- libcomplex 1.1 code, we commit the changes we made to get it
- looking that way.</para>
-
- <para>Our <filename>current</filename> branch now contains the
- new vendor drop. We tag the new version (in the same way we
- previously tagged the version 1.0 vendor drop), and then merge
- the differences between the tag of the previous version and
- the new current version into our main development
- branch.</para>
-
<screen>
$ cd working-copies/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \
@@ -2132,28 +2184,31 @@
…
</screen>
- <para>In the trivial use-case, the new version of our
- third-party tool would look, from a files-and-directories
- point of view, just like the previous version. None of the
- libcomplex source files would have been deleted, renamed or
- moved to different locations—the new version would
- contain only textual modifications against the previous one.
- In a perfect world, our modifications would apply cleanly to
- the new version of the library, with absolutely no
- complications or conflicts.</para>
-
- <para>But things aren't always that simple, and in fact it is
- quite common for source files to get moved around between
- releases of software. This complicates the process of ensuring
- that our modifications are still valid for the new version of
- code, and can quickly degrade into a situation where we have to
- manually recreate our customizations in the new version. Once
- Subversion knows about the history of a given source
- file—including all its previous locations—the
- process of merging in the new version of the library is pretty
- simple. But we are responsible for telling Subversion how the
- source file layout changed from vendor drop to vendor
- drop.</para>
+ <para>En el caso de uso trivial, la nueva versión de nuestra
+ herramienta de terceros sería, desde un punto de vista
+ de ficheros y directorios, justo igual que nuestra
+ versión anterior. Ninguno de los ficheros de código
+ fuente de libcomplex habría sido borrado, renombrado o
+ movido a una localización diferente—la nueva
+ versión solamente tendría modificaciones textuales
+ contra la anterior. En un mundo perfecto, nuestras
+ modificaciones serían aplicadas limpiamente sobre la
+ nueva versión de la librería, absolutamente sin
+ complicaciones o conflictos.</para>
+
+ <para>Pero las cosas no son siempre tan simples, y de hecho
+ es bastante habitual que ficheros de código fuente sean
+ desplazados entre versiones de un software. Esto complica
+ el proceso de asegurarnos que nuestras modificaciones son
+ todavía válidas para la nueva versión del código, y puede
+ degenerar rápidamente en la situación donde tenemos que
+ recrear manualmente nuestras personalizaciones para la nueva
+ versión. Una vez Subversion conoce la historia de un fichero
+ de código fuente determinado—incluyendo todas sus
+ localizaciones previas—el proceso de fusionar la nueva
+ versión de la librería es bastante simple. Pero somos
+ responsables de indicar a Subversion cómo ha cambiado la
+ estructura de ficheros de un hito de proveedor a otro.</para>
</sect2>
More information about the svnbook-dev
mailing list