Merge pull request #146 from DiegoFRamirez/new_corrections

Review on Section 09 initialized (four first chapters concluded)

Author: andres-mancera

book/09-git-and-other-scms/sections/client-hg.asc

@@ -1,19 +1,19 @@
 ==== Git y Mercurial
 
-(((Interoperation with other VCSs, Mercurial)))
+(((Interoperación con otros VCS, Mercurial)))
 (((Mercurial)))
 El universo DVCS es más grande que el de Git.
 De hecho, hay muchos otros sistemas en este espacio, cada uno con su propio ángulo sobre cómo hacer el control de versión distribuida correctamente.
 Aparte de Git, el más popular es Mercurial, y los dos son muy similares en muchos aspectos.
 
-La buena noticia, si prefiere el comportamiento del cliente de Git pero que está trabajando con un proyecto cuyo código fuente está controlado con Mercurial, es que hay una manera de usar Git como cliente para un repositorio alojado en Mercurial.
+La buena noticia, si prefiere el comportamiento del cliente de Git pero está trabajando con un proyecto cuyo código fuente está controlado con Mercurial, es que hay una manera de usar Git como cliente para un repositorio alojado en Mercurial.
 Dado que la forma en que Git habla con los repositorios del servidor es a través de controles remotos, no debería sorprendernos que este puente se implemente como un ayudante remoto.
-El nombre del proyecto es git-remote-hg, y se puede encontrar en https://github.com/felipec/git-remote-hg[].
+El nombre del proyecto es 'git-remote-hg', y se puede encontrar en https://github.com/felipec/git-remote-hg[].
 
 ===== git-remote-hg
 
-Primero, necesitas instalar git-remote-hg.
-Esto básicamente implica dejar caer su archivo en algún lugar de tu camino, así:
+Primero, necesita instalar git-remote-hg.
+Esto básicamente implica dejar caer su archivo en algún lugar de su camino, así:
 
 [source,console]
 ----
@@ -24,7 +24,7 @@ $ chmod +x ~/bin/git-remote-hg
 
 ... asumiendo que `~ / bin` está en su` $ PATH`.
 Git-remote-hg tiene otra dependencia: la biblioteca `mercurial` para Python.
-Si tienes instalado Python, es tan sencillo como:
+Si tiene instalado Python, es tan sencillo como:
 
 [source,console]
 ----
@@ -33,12 +33,12 @@ $ pip install mercurial
 
 (Si no tiene instalado Python, visite https://www.python.org/[] y consígalo primero.)
 
-Lo último que necesitarás es el cliente Mercurial.
+Lo último que necesitará es el cliente Mercurial.
 Vaya a http://mercurial.selenic.com/[] e instálelo si aún no lo ha hecho.
 
-Ahora estás listo para el rock.
-Todo lo que necesitas es un repositorio Mercurial al que puedes presionar.
-Afortunadamente, todos los repositorios de Mercurial pueden actuar de esta manera, así que solo usaremos el repositorio de "hola mundo" que todos usan para aprender Mercurial:
+Ahora está listo para el rock.
+Todo lo que necesita es un repositorio Mercurial al que pueda presionar.
+Afortunadamente, todos los repositorios de Mercurial pueden actuar de esta manera, así que sólo usaremos el repositorio de "hola mundo" que todos usan para aprender Mercurial:
 
 [source,console]
 ----
@@ -62,7 +62,7 @@ $ git log --oneline --graph --decorate
 ----
 
 Notará que el uso de un repositorio de Mercurial utiliza el comando `git clone` estándar.
-Esto se debe a que git-remote-hg está funcionando a un nivel bastante bajo, utilizando un mecanismo similar a cómo se implementa el protocolo HTTP / S de Git (auxiliares remotos).
+Esto se debe a que git-remote-hg está funcionando a un nivel bastante bajo, utilizando un mecanismo similar a como se implementa el protocolo HTTP / S de Git (auxiliares remotos).
 Dado que Git y Mercurial están diseñados para que cada cliente tenga una copia completa del historial del repositorio, este comando hace un clon completo, incluyendo todo el historial del proyecto, y lo hace con bastante rapidez.
 
 El comando de registro muestra dos confirmaciones, la última de las cuales es señalada por un montón de refs.
@@ -91,12 +91,12 @@ $ tree .git/refs
 9 directories, 5 files
 ----
 
-Git-remote-hg está tratando de hacer las cosas más idiomáticamente Git-esque, pero bajo el capó es la gestión de la cartografía conceptual entre dos sistemas ligeramente diferentes.
+'Git-remote-hg' está tratando de hacer las cosas más idiomáticamente 'Git-esque', pero bajo el capó es la gestión de la cartografía conceptual entre dos sistemas ligeramente diferentes.
 El directorio `refs/hg` es donde se almacenan las referencias remotas reales.
-Por ejemplo, el `refs/hg/origen/branches/default` es un archivo ref de Git que contiene el SHA-1 que comienza con ``ac7955c'', que es el commit que señala `master`.
+Por ejemplo, el `refs/hg/origen/branches/default` es un archivo 'ref' de Git que contiene el SHA-1 que comienza con ``ac7955c'', que es el 'commit' que señala `master`.
 Así que el directorio `refs/hg` es como un`refs/remotes/origen' falso, pero tiene la distinción añadida entre marcadores y ramas.
 
-El archivo `notes/hg` es el punto de partida de cómo git-remote-hg asigna los hashes de commit de Git a los identificadores de cambios de Mercurial.
+El archivo `notes/hg` es el punto de partida de cómo 'git-remote-hg' asigna los hashes de 'commit' de Git a los identificadores de cambios de Mercurial.
 Vamos a explorar un poco:
 
 [source,console]
@@ -121,26 +121,26 @@ $ git cat-file -p ac9117f
 
 Así que `refs/notes/hg` apunta a un árbol, que en la base de datos de objetos Git es una lista de otros objetos con nombres.
 `Git ls-tree` genera el modo, el tipo, el hash de objeto y el nombre de archivo de elementos dentro de un árbol.
-Una vez que excavamos hacia abajo a uno de los elementos del árbol, encontramos que en su interior hay un blob llamado ``ac9117f'' (el hash SHA-1 del commit apuntado por `master`), con contenidos ``0a04b98'' Que es el identificador del conjunto de cambios Mercurial en la punta de la rama `default`).
+Una vez que excavamos hacia abajo a uno de los elementos del árbol, encontramos que en su interior hay un blob llamado ``ac9117f'' (el hash SHA-1 del 'commit' apuntado por `master`), con contenidos ``0a04b98''. Que es el identificador del conjunto de cambios Mercurial en la punta de la rama `default`).
 
-La buena noticia es que en general no tenemos que preocuparnos por todo esto.
+La buena noticia es, que en general, no tenemos que preocuparnos por todo esto.
 El flujo de trabajo típico no será muy diferente de trabajar con un control remoto de Git.
 
-Hay una cosa más a la que debemos atender antes de continuar: ignora.
-Mercurial y Git usan un mecanismo muy similar para esto, pero es probable que no quieras realmente comprometer un archivo `.gitignore` en un repositorio de Mercurial.
-Afortunadamente, Git tiene una forma de ignorar los archivos que son locales a un repositorio en disco, y el formato Mercurial es compatible con Git, por lo que sólo tienes que copiarlo:
+Hay una cosa más a la que debemos atender antes de continuar: 'ignore'.
+Mercurial y Git usan un mecanismo muy similar para esto, pero es probable que no quiera realmente comprometer un archivo `.gitignore` en un repositorio de Mercurial.
+Afortunadamente, Git tiene una forma de ignorar los archivos que son locales a un repositorio en disco, y el formato Mercurial es compatible con Git, por lo que sólo tiene que copiarlo:
 
 [source,console]
 ----
 $ cp .hgignore .git/info/exclude
 ----
 
-El archivo `.git / info / exclude 'actúa como un` .gitignore`, pero no está incluido en commits.
+El archivo `.git / info / exclude 'actúa como un` .gitignore`, pero no está incluido en 'commits'.
 
 
 ===== Flujo de Trabajo
 
-Supongamos que hemos hecho algunos trabajos e hicimos algunos commit en la rama `master` y estamos listos para enviarlo al repositorio remoto.
+Supongamos que hemos hecho algunos trabajos e hicimos algunos 'commit' en la rama `master` y estamos listos para enviarlo al repositorio remoto.
 A continuación, le mostramos nuestro repositorio:
 
 [source,console]
@@ -152,7 +152,7 @@ $ git log --oneline --graph --decorate
 * 65bb417 Create a standard "hello, world" program
 ----
 
-Nuestra rama `master` está a dos compromisos por delante de `origin/master`, pero estos dos commits sólo existen en nuestra máquina local.
+Nuestra rama `master` está a dos compromisos por delante de `origin/master`, pero estos dos 'commits' sólo existen en nuestra máquina local.
 Veamos si alguien más ha estado haciendo un trabajo importante al mismo tiempo:
 
 [source,console]
@@ -172,8 +172,8 @@ $ git log --oneline --graph --decorate --all
 * 65bb417 Create a standard "hello, world" program
 ----
 
-Puesto que utilizamos el indicador `--all`, vemos las` `notes '' refs que son utilizadas internamente por git-remote-hg, pero podemos ignorarlas.
-El resto es lo que esperábamos; `Origen / master` ha avanzado por una comisión, y nuestra historia ha divergido ahora.
+Puesto que utilizamos el indicador `--all`, vemos las ``notes refs'' que son utilizadas internamente por 'git-remote-hg', pero podemos ignorarlas.
+El resto es lo que esperábamos; `origin / master` ha avanzado por una comisión, y nuestra historia ha divergido ahora.
 A diferencia de los otros sistemas con los que trabajamos en este capítulo, Mercurial es capaz de manejar fusiones, por lo que no vamos a hacer nada extravagante.
 
 [source,console]
@@ -229,7 +229,7 @@ o  0   0a04b987be5a   2005-08-26 01:20 -0700   mpm
      Create a standard "hello, world" program
 ----
 
-El conjunto de cambios numerado _2_ fue hecho por Mercurial, y los conjuntos de cambios numerados _3_ y _4_ fueron hechos por git-remote-hg, al empujar los commit hechos con Git.
+El conjunto de cambios numerado _2_ fue hecho por Mercurial, y los conjuntos de cambios numerados _3_ y _4_ fueron hechos por 'git-remote-hg', al empujar los 'commit' hechos con Git.
 
 ===== Branches(Ramas) y Bookmarks(Marcadores)
 
@@ -238,7 +238,7 @@ En Mercurial, este tipo de referencia se llama marcador, y se comporta de la mis
 
 El concepto de Mercurial de una "rama" es más pesado.
 La rama en la que se realiza un conjunto de cambios se registra con el conjunto de cambios, lo que significa que siempre estará en el historial del repositorio.
-He aquí un ejemplo de un commit que se hizo en la rama `develop`:
+He aquí un ejemplo de un 'commit' que se hizo en la rama `develop`:
 
 [source,console]
 ----
@@ -251,8 +251,8 @@ date:        Thu Aug 14 20:06:38 2014 -0700
 summary:     More documentation
 ----
 
-Observe la línea que comienza con ``Branch''.
-Git no puede realmente replicar esto (y no necesita, ambos tipos de rama puede representarse como una referencia Git), pero git-remote-hg necesita entender la diferencia, porque Mercurial se preocupa.
+Observe la línea que comienza con ``branch''.
+Git no puede realmente replicar esto (y no necesita, ambos tipos de rama puede representarse como una referencia Git), pero 'git-remote-hg' necesita entender la diferencia, porque Mercurial se preocupa.
 
 Crear marcadores de Mercurial es tan fácil como crear ramas de Git.
 En el lado Git:
@@ -299,7 +299,7 @@ o  0   0a04b987be5a   2005-08-26 01:20 -0700   mpm
 Tenga en cuenta la nueva etiqueta `[featureA]` en la revisión 5.
 Éstos actúan exactamente como las ramas de Git en el lado de Git, con una excepción: usted no puede suprimir un marcador del lado de Git (ésta es una limitación de ayudantes remotos).
 
-Puedes trabajar con una rama ``heavyweight'' de Mercurial si: introduces ramas en los espacios para `branches` así:
+Puede trabajar con una rama ``heavyweight'' de Mercurial si: introduce ramas en los espacios para `branches` así:
 
 [source,console]
 ----
@@ -347,9 +347,9 @@ o    changeset:   5:bd5ac26f11f9
 
 El nombre de la rama ``permanent'' se registró en el conjunto de cambios marcados con _7_.
 
-Desde el lado de Git, el trabajo con cualquiera de estos estilos de rama es el mismo: sólo checkout, commit, fetch, merge, pull y push como lo haría normalmente.
+Desde el lado de Git, el trabajo con cualquiera de estos estilos de rama es el mismo: sólo ``checkout'', ``commit'', ``fetch'', ``merge'', ``pull'' y ``push'' como lo haría normalmente.
 Una cosa que usted debe saber es que Mercurial no apoya la historia de la reescritura, agregando solamente a ella.
-Esto es lo que nuestro repositorio de Mercurial parece después de un rebase interactivo y un force-push:
+Esto es lo que nuestro repositorio de Mercurial parece después de un ``rebase interactivo'' y un ``force-push'':
 
 [source,console]
 ----
@@ -388,11 +388,11 @@ o  0   0a04b987be5a   2005-08-26 01:20 -0700   mpm
      Create a standard "hello, world" program
 ----
 
-CHangesets _8_, _9_ y _10_ han sido creados y pertenecen a la rama `permanent`, pero los viejos changesets siguen ahí.
+CHangesets _8_, _9_ y _10_ han sido creados y pertenecen a la rama `permanent`, pero los viejos ``changesets'' siguen ahí.
 Esto puede ser *muy* confuso para sus compañeros de equipo que están usando Mercurial, así que trate de evitarlo.
 
 
 ===== Resumen de Mercurial
 
-Git y Mercurial son bastante similares que trabajar a través de la frontera es bastante indoloro.
+Git y Mercurial son bastante similares, por lo que trabajar a través de la frontera es bastante indoloro.
 Si evita cambiar el historial que ha dejado su máquina (como se recomienda generalmente), puede que ni siquiera sepa que el otro extremo es Mercurial.