Commits

jerojasro  committed 9da096d

changed "historia" to "historial".
changed "archivo" to "fichero"
corrected some typos

  • Participants
  • Parent commits aa01d35

Comments (0)

Files changed (15)

File es/branch.tex

 mover el tag hacia la revisión correcta tan pronto como localice el
 error.
 
-Mercurial almacena las etiquetas en un archivo controlado por revisiones en
-su repositorio. Si ha creado etiquetas, las encontrará en un archivo
+Mercurial almacena las etiquetas en un fichero controlado por revisiones en
+su repositorio. Si ha creado etiquetas, las encontrará en un fichero
 llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
-Mercurial modifica este archivo, y automáticamente hace consignación del
+Mercurial modifica este fichero, y automáticamente hace consignación del
 cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
 verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
 \interaction{tag.tip}
 
 \subsection{Manejo de conflictos entre etiquetas durante una fusión}
 
-Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
+Es usual no tener que preocuparse por el fichero \sfilename{.hgtags},
 pero aveces hace su aparición durante una fusión. El formato del
-archivo es sencillo: Consiste de una serie de líneas. Cada línea
+fichero es sencillo: Consiste de una serie de líneas. Cada línea
 comienza con un hash de Conjunto de Cambios, seguido por un espacio,
 seguido por el nombre de un tag.
 
-Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
+Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
 durante una fusión, hay un detalle para tener en cuenta al modificar
-el archivo \sfilename{.hgtags}:
+el fichero \sfilename{.hgtags}:
 cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca}
-lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
-lee la versión \emph{consignada más reciente} del archivo.
+lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
+lee la versión \emph{consignada más reciente} del fichero.
 
 Una consecuencia desafortunada de este diseño es que usted no puede
-verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta
+verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
 \emph{después} de haber consignado(hecho commit). Así que si se
 encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
 fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
-consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, 
+consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
 reportará el lugar del error, que podrá arreglar y después
 consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
 asegurar que su arreglo fue correctamente aplicado.
 Puede haber notado que la orden \hgcmd{clone} tiene la opción
 \hgopt{clone}{-r} que le permite clonar una copia exacta del
 repositorio hasta un conjunto de cambios específico. El nuevo clon no
-tendrá historia posterior a la revisión que usted haya
+tendrá historial posterior a la revisión que usted haya
 especificado. Esta forma de interactuar puede sorprender a los
 desprevenidos.
 
-Recuerde que un tag se almacena como una revisión al archivo
+Recuerde que un tag se almacena como una revisión al fichero
 \sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el
 conjunto de cambios en el cual este se almacena necesariamente se
 refiere a un conjunto de cambios anterior. Cuando ejecuta
 \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
-\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo
+\texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
 el tag} que usó para clonar el repositorio. El resultado es que tendrá
-exactamente el subconjunto correcto de la historia del proyecto en el
+exactamente el subconjunto correcto de el historial del proyecto en el
 nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
 
 \subsection{Cuando las etiquetas permanentes son demasiado}
 
 Dado que las etiquetas de Mercurial están controladas por revisiones y se
-llevan en la historia del proyecto, todas las personas involucradas
+llevan en el historial del proyecto, todas las personas involucradas
 verán las etiquetas que usted haya creado. El hecho de dar nombres a las
 revisiones tiene usos más allá que simplemente hacer notar que la
 revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
 
 Para estos casos, lo que posiblemente desearía serían tags
 \emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l}
-de la orden \hgcmd{tag}.  Esto guardará el tag en un archivo llamado
+de la orden \hgcmd{tag}.  Esto guardará el tag en un fichero llamado
 \sfilename{.hg/localtags}.  A diferencia de \sfilename{.hgtags},
 \sfilename{.hg/localtags} no está controlado por revisiones.
 Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá
 
 Usualmente la gente se refiere a esas direcciones
 concurrentes de desarrollo es como ``ramas''.  Aunque hemos visto que
-en variadas ocasiones Mercurial trata a \emph{toda la historia} como
+en variadas ocasiones Mercurial trata a \emph{toda el historial} como
 una serie de ramas y fusiones.  Realmente lo que tenemos aquí es dos
 ideas que se relacionan periféricamente, pero que en esencia comparten
 un nombre.
 facilidad; y es difícil cometer errores. Hay una relación uno a uno
 entre las ramas y los directorios con los que está trabajando en su
 sistema. Esto le permite usar emplear herramientas usuales(para los
-nuevos a Mercurial) para trabajar con los archivos dentro de su
+nuevos a Mercurial) para trabajar con los ficheros dentro de su
 rama/repositorio.
 
 Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
 la orden \hgcmd{branch}.  ¿Qué reportan las ordenes \hgcmd{status} y
 \hgcmd{tip} commands report?
 \interaction{branch-named.status}
-Nada cambia en el directorio actual, y no se ha añadido nada a la
-historia. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
+Nada cambia en el directorio actual, y no se ha añadido nada al
+historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
 un efecto permanente; solamente le indica a que nombre de rama usará
 la \emph{próxima} vez que consigne un conjunto de cambios.
 
 Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
 y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
 puesto que esto solamente implica ir linealmente hacia adelante y
-atrás en nuestra historia de cambios.
+atrás en nuestro historial de cambios.
 \interaction{branch-named.update-switchy}
 
 Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
 
 En el caso más sencillo, dar un nombre a cada rama ofrece un registro
 permanente acerca de en qué conjunto de cambios se generó la rama.
-Esto le ofrece más contexto cuando esté tratando de seguir la
-historia de un proyecto ramificado de larga vida.
+Esto le ofrece más contexto cuando esté tratando de seguir el
+historial de un proyecto ramificado de larga vida.
 
 Si está trabajando con repositorios compartidos, puede configurar el gancho
 \hook{pretxnchangegroup} para que cada uno bloquee los cambios con

File es/cmdref.tex

 \optref{add}{X}{exclude}
 \optref{add}{n}{dry-run}
 
-\cmdref{diff}{imprime los cambios en la historia o el directorio actual}
+\cmdref{diff}{imprime los cambios en el historial o el directorio actual}
 
 Mostrar las diferencias entre revisiones para ficheros especificados o
 directorios, con el formato unificado diff.  Si desea ver una
 descripción del formato unificado diff, ver la sección~\ref{sec:mq:patch}.
 
 De forma predeterminada, esta orden no imprime las diferencias para
-los archivos binarios que Mercurial esté siguiendo.  Para controlar
+los ficheros binarios que Mercurial esté siguiendo.  Para controlar
 este comportamiento, vea las opciones \hgopt{diff}{-a} y
 \hgopt{diff}{--git}.
 

File es/collab.tex

 capacidades útiles.
 
 Para uso interactivo, la interfaz le permite visualizar uno o varios
-repositorios. Puede ver la historia de un repositorio, examinar cada
+repositorios. Puede ver el historial de un repositorio, examinar cada
 cambio(comentarios y diferencias), y ver los contenidos de cada
 directorio y fichero.
 
 CGI, como en la sección~\ref{sec:collab:cgi}.  Publicar sobre HTTP
 satisface las necesidades de la gente que no tiene permisos de
 publicación y de aquellos que quieren usar navegadores web para
-visualizar la historia del repositorio.
+visualizar el historial del repositorio.
 
 \subsection{Trabajo con muchas ramas}
 
 La orden \hgcmd{serve} \emph{no} es un servidor web de propósito
 general. Solamente puede hacer dos cosas:
 \begin{itemize}
-\item Permitir que se pueda visualizar la historia del repositorio que
+\item Permitir que se pueda visualizar el historial del repositorio que
   está sirviendo desde navegadores web.
 \item Hablar el protocolo de conexión de Mercurial para que puedan hacer
   \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio.
   este síntoma.
 \item El fichero de usuario \sfilename{authorized\_keys} puede tener
   un problema.  Si alguien distinto al usuario es dueño o puede
-  escribir el archivo, el daemonio ssh no confiará o lo leerá.
+  escribir el fichero, el daemonio ssh no confiará o lo leerá.
 \end{itemize}
 
 En un mundo ideal, debería poder ejecutar la siguiente orden
 completa al repositorio que desea servir.
 
 En este punto, cuando trate de recargar la página, deberá visualizar
-una linda vista HTML de la historia de su repositorio. Uff!
+una linda vista HTML de el historial de su repositorio. Uff!
 
 \subsubsection{Configuración de lighttpd}
 
 virtual \dirname{ruta/este/repo} en lugar de \dirname{este/repo}.
 
 El guión \sfilename{hgwebdir.cgi} buscará recursivamente en cada
-directorio listado en la sección \texttt{collections} de su archivo de
+directorio listado en la sección \texttt{collections} de su fichero de
 configuración, pero \texttt{no} hará el recorrido recursivo dentro de
 los repositorios que encuentre.
 
 El mecanismo de \texttt{collections} permite publicar fácilmente
 repositorios de una forma ``hacer y olvidar''.  Solamente requiere
-configurar el guión CGI y el archivo de configuración una vez.
+configurar el guión CGI y el fichero de configuración una vez.
 Después de eso puede publicar y sacar de publicación un repositorio en
 cualquier momento incluyéndolo o excluyéndolo de la jerarquía de
 directorios en la cual le haya indicado a \sfilename{hgwebdir.cgi} que
 está en el lado derecho de cada definición, mientras que la ruta al
 repositorio está a la derecha.  Note que no tiene que haber relación
 alguna entre la ruta virtual que elija y el lugar del repositorio en
-su sistema de archivos.
+su sistema de ficheros.
 
 Si lo desea, puede usar los dos mecanismos \texttt{collections} y
-\texttt{paths} simultáneamente en un sólo archivo de configuración.
+\texttt{paths} simultáneamente en un sólo fichero de configuración.
 
 \begin{note}
   Si varios repositorios tienen la misma ruta virtual,
 opciones de configuración para establecer. Todas ellas en la sección
 \rcsection{web}.
 \begin{itemize}
-\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de archivos
+\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de ficheros
   de descarga soportará Mercurial.  Si habilita esta característica,
   los usuarios de la interfaz web podrán descargar una copia de la
   revisión del repositorio que estén viendo. Para activar la
     style = gitweb
   \end{codesample4}
 \item[\rcitem{web}{templates}] Ruta.  Directorio en el que se buscarán
-  los archivos plantilla.  De forma predeterminada, busca en el
+  los ficheros plantilla.  De forma predeterminada, busca en el
   directorio en el cual fue instalado.
 \end{itemize}
 Si usa \sfilename{hgwebdir.cgi}, puede añadir otras opciones de

File es/concepts.tex

 
 Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda
 escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es
-seguro incluso sobre sistemas de archivos notoriamente hostiles al
+seguro incluso sobre sistemas de ficheros notoriamente hostiles al
 bloqueo, como NFS). Si un repositorio está bloqueado, los escritores
 esperarán un buen rato para revisar si el repositorio ya ha sido
 desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,

File es/daily.tex

 adicionado no está relacionado con el fichero anterior que tenía el
 mismo nombre.
 
-\subsection{Al eliminar un fichero no se afecta su historia}
+\subsection{Al eliminar un fichero no se afecta su historial}
 
 Es preciso tener en cuenta que al eliminar un fichero se tiene
 dos efectos solamente.
 \item Mercurial deja de hacer seguimiento a los cambios del fichero
   desde la próxima consignación.
 \end{itemize}
-Al eliminar un fichero \emph{no} se altera de ninguna manera la
-\emph{historia} del mismo.
+Al eliminar un fichero \emph{no} se altera de ninguna manera el
+\emph{historial} del mismo.
 
 Si actualiza su directorio de trabajo a un conjunto de cambios en el
 cual esl fichero que eliminó aún era tenido en cuenta, reaparecerá en

File es/filenames.tex

 cadena. Para buscar coincidencias en cualquier sitio dentro de una
 cadena, empiece su patrón con un ``\texttt{.*}''.
 
-\section{Filtrado de archivos}
+\section{Filtrado de ficheros}
 
 Mercurial no sólo le provee una variedad de formas para especificar
 ficheros; le permite limitar aún más dichos ficheros mediante el uso
 \subsection{Detección de conflictos de mayúsculas/minúsculas}
 
 Al operar en el directorio de trabajo, Mercurial respeta la política
-de nombrado del sistema de archivos en que se encuentre el directorio
+de nombrado del sistema de ficheros en que se encuentre el directorio
 de trabajo. Si el sistema de ficheros conserva las diferencias entre
 mayúsculas, pero no es sensible a ellas, Mercurial tratará los nombres
 que sólo difieren en mayúsculas como uno solo y el mismo.

File es/hgext.tex

 buen desempeño, los autores de Mercurial han optimizado este código en
 la medida de lo posible.  Sin embargo, no puede obviarse el hecho de
 que cuando ejecuta \hgcmd{status}, Mercurial tendrá que hacer por lo
-menos una costosa llamada al sistema por cada archivo administrado
+menos una costosa llamada al sistema por cada fichero administrado
 para determinar si ha cambiado desde la última vez que se consignó.
 Para un repositorio suficientemente grande, puede tardar bastante
 tiempo.
 
 Para mostrar en números la magnitud de este efect, creé un repositorio
-que contenía 150.000 archivos administrador.  Tardó diez segundos para
+que contenía 150.000 ficheros administrador.  Tardó diez segundos para
 ejecutar \hgcmd{status}, a pesar de que \emph{ninguno} de los ficheros
 había sido modificado.
 
 Muchos sistemas operativos modernos contienen una facilidad de
-notificación de archivos.  Si un programa se registra con un servicio
+notificación de ficheros.  Si un programa se registra con un servicio
 apropiado, el sistema operativo le notificará siempre que un fichero
 de interés haya sido creado, modificado o borrado.  En sistemas Linux,
 el componente del núcleo que lo hace se llama \texttt{inotify}.

File es/intro.tex

 Hay muchas razones por las cuales usted o su equipo desearía usar una
 herramienta automática de control de revisiones para un proyecto.
 \begin{itemize}
-        %TODO historia
-\item Llevar registro de la historia y la evolución de su proyecto, para
+\item Llevar registro de el historial y la evolución de su proyecto, para
   evitar hacer la tarea manualmente. Por cada cambio, tendrá una
   bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
   \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
 desarrollado la versión moderna de CVS.  CVS adquirió posteriormente 
 la habilidad de operar sobre una conexión de red, dotándolo de una
 arquitectura, cliente/servidor. La arquitectura de CVS es
-%TODO historia/historial
-centralizada; La historia del proyecto está únicamente en el
+centralizada; el historial del proyecto está únicamente en el
 repositorio central.  Los espacios de trabajo de los clientes
 contienen únicamente copias recientes de las versiones de los
 ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
 A comienzos de los noventa~(1990s), Sun MicroSystems desarrollo un
 temprano sistema distribuido de control de revisiones llamado
 TeamWare.
-Un espacio de trabajo TeamWare contiene una copia completa de la
-historia del proyecto. TeamWare no tiene la noción de repositorio
-central. (CVS se basaba en RCS para el almacenamiento de su historia;
+Un espacio de trabajo TeamWare contiene una copia completa de el
+historial del proyecto. TeamWare no tiene la noción de repositorio
+central. (CVS se basaba en RCS para el almacenamiento de su historial;
 TeamWare usaba SCCS.)
 
 A medida que avanzaba la decada de los noventa, se empezó a
 a trabajar en él, y ese proyecto usa una herramienta de control
 distribuido de revisiones, usted es de inmediato un par con la gente que se
 considera el ``alma'' del proyecto.  Si ellos publican sus
-%TODO historia/historial
-repositorios, usted puede copiar inmediatamente la historia del proyecto,
+repositorios, usted puede copiar inmediatamente el historial del proyecto,
 hacer cambios y guardar su trabajo, usando las mismas herramientas de
 la misma forma que ellos. En contraste, con una herramienta
 centralizada, usted debe usar el programa en un modo ``sólo lectura'' a
 En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
 diferencias. Con un sistema centralizado de control de revisiones, el
 proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
-%TODO historia/historial
-forma muy manual.  Usted tiene que decidir qué historia de revisiones va a
+forma muy manual.  Usted tiene que decidir qué historial de revisiones va a
 ``ganar'', e injertar los cambios del otro equipo en el árbol de alguna
-%TODO historia/historial
 manera. Con esto usualmente se pierde algo o todo del historial de la
 revisión de alguna de las partes.
 
 desean mantener control completo sobre sus proyectos, y creen que las
 herramientas centralizadas les dan tal control. En todo caso, si este
 es su parecer, y usted publica sus repositorios de CVS o Subversion, hay
-muchas herramientas disponibles que pueden obtener la historia
-completa (aunque sea lentamente) y recrearla en otro sitio que usted no
+muchas herramientas disponibles que pueden obtener el historial
+completo (aunque sea lentamente) y recrearlo en otro sitio que usted no
 controla. Siendo así un control ilusorio, puesto que está impidiendo
 la fluidez de colaboración en lugar de prevenir que alguien se sienta
-impulsado a obtener una copia y hacer una bifurcación con su historia.
+impulsado a obtener una copia y hacer una bifurcación con su historial.
 
 \subsection{Ventajas para proyectos comerciales}
 
 sistema distribuido de control de versiones al resolver problemas en
 el sitio del cliente. La herramienta le permitirá generar
 construcciones a la medida, probar diferentes arreglos de forma
-independiente y buscar de forma eficiente las fuentes de fallos en la
-historia y regresiones en los ambientes de los clientes, todo sin
+independiente y buscar de forma eficiente las fuentes de fallos en el
+historial y regresiones en los ambientes de los clientes, todo sin
 necesidad de conectarse al servidor de su compañía.
 
 \section{¿Por qué elegir Mercurial?}
 
 En un proyecto pequeño, usted puede comenzar a trabajar con Mercurial en
 pocos momentos. Crear nuevos cambios y ramas, transferir cambios (localmente
-o por la red); y las operaciones relacionadas con el estado y la
-historia son rápidas. Mercurial buscar ser ligero y no incomodar en su
+o por la red); y las operaciones relacionadas con el estado y el
+historial son rápidas. Mercurial buscar ser ligero y no incomodar en su
 camino combinando poca sobrecarga cognitiva con operaciones
 asombrosamente rápidas.
 
 información frente a la revisión actual (\texttt{diff}).  Como
 resultado, la copia de trabajo de Subversion termina siendo del mismo
 tamaño o más grande que un repositorio de Mercurial y el directorio de
-trabajo, a pesar de que el repositorio de Mercurial contiene la
-historia completa  del proyecto.
+trabajo, a pesar de que el repositorio de Mercurial contiene el
+historial completo  del proyecto.
 
 Subversion tiene soporte amplio de otras herramientas. Mercurial por
 ahora está bastante atrás en este aspecto.  Esta diferencia está
   Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual
 que Mercurial, Subversion tiene un excelente manual de usuario.
 
-Dado que Subversion no almacena la historia de revisiones en el
+Dado que Subversion no almacena el historial de revisiones en el
 cliente, es muy bueno para administrar proyectos que tienen muchos
 ficheros binarios grandes y opacos. Si consigna cincuenta revisiones
 de un fichero de 10MB que no es comprimible, el esapacio en el cliente
 ventaja significativa en un proyecto donde los ficheros binarios sean
 usados ampliamente.
 
-Mercurial puede importar la historia de revisiones de un repositorio
-de Subversion. También puede exportar historia de revisiones a un
+Mercurial puede importar el historial de revisiones de un repositorio
+de Subversion. También puede exportar el historial de revisiones a un
 repositorio de Subversion.  De esta forma es sencillo ``dar un
 vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
-a dar el paso. La conversión de la historia es incremental, de modo
+a dar el paso. La conversión de el historial es incremental, de modo
 que puede aplicar una conversión inicial, y después conversiones
 pequeñas y adicionales posteriormente para traer nuevos cambios.
 
 consignar exitósamente parte del cambio y estar bloqueada por la
 necesidad de una mezcla, forzando a otras personas a ver solamente una
 porción del trabajo que estaban buscando hacer.  Esto afecta también
-%TODO historia/historial
-la forma como usted trabaja con la historia del proyecto. Si quiere
+la forma como usted trabaja con el historial del proyecto. Si quiere
 ver todas las modificaciones que alguien hizo como parte de una tarea,
 necesitará inspeccionar manualmente las descripciones y las marcas de
 tiempo de cambio de cada fichero involucrado (esto, si usted saber
 repositorio. Yo no recomendaría un repositorio de CVS para proyecto
 alguno, ni existente ni nuevo.
 
-Mercurial puede importar la historia de revisiones de CVS.  De todas
+Mercurial puede importar el historial de revisiones de CVS.  De todas
 maneras hay ciertas precauciones que aplican; las cuales también son
 necesarias para cualquier herramienta importadora de historial de
 CVS. Debido a la falta de atomicidad de cambios y el no versionamiento
 de la jerarquía del sistema de ficheros, es imposible reconstruir
-completamente la historia de CVS con precisión; hay cierto trabajo de
+completamente el historial de CVS con precisión; hay cierto trabajo de
 conjetura involucrado y los renombramientos tampoco se
 mostrarán. Debido a que gran parte de la administración avanzada de
 CVS tiene que hacerse manualmente y por lo tanto es proclive al error,
 dos de los problemas menos interesantes de los que puedo retomar de mi
 experiencia personal).
 
-%TODO historia/historial
-Mercurial puede importar la historia de revisiones de un repositorio
+Mercurial puede importar el historial de revisiones de un repositorio
 CVS.
 
 \subsection{Herramientas comerciales}
 Mercurial viene con una extensión llamada \hgext{convert}, que puede
 importar historiales de revisiones de forma incremental desde varias
 herramientas de control de revisiones. Por ``incremental'', quiero
-decir que puede migrar toda la historia de un proyecto en una primera
+decir que puede migrar toda el historial de un proyecto en una primera
 instancia y después volver a ejecutar la migración posteriormente para
 obtener los nuevos cambios que han sucedido después de la migración
 inicial.

File es/mq-collab.tex

 tiene problemas manejando nombres de parches que contienen separadores
 de ruta.
 
-\subsection{Ver la historia de un parche}
+\subsection{Ver el historial de un parche}
 \label{mq-collab:tips:interdiff}
 
 Si usted está desarrollando un conjunto de parches en un período de
 tiempo grande, es una buena idea mantenerlos en un repositorio, como
 se discutió en la sección~\ref{sec:mq:repo}.  Si lo hace, notará
-rápidamente que usar el comando \hgcmd{diff} para mirar la historia
+rápidamente que usar el comando \hgcmd{diff} para mirar el historial
 del repositorio no es viable. Esto es debido en parte a que usted está
 mirando la segunda derivada del código real (el diff de un diff), pero
 también porque MQ añade ruido al proceso al modificar las marcas de

File es/mq-ref.tex

   el nuevo conjunto de cambios que representa el parche.
 \item Las modificaciones a los ficheros a los que se les da
   seguimiento en el directorio de trabajo se añade al parche.
-\item Los cambios a los archivos a los que se les da seguimiento con
+\item Los cambios a los ficheros a los que se les da seguimiento con
   \hgcmd{add}, \hgcmd{copy}, \hgcmd{remove}, o \hgcmd{rename}.  Se
   añaden al parche los ficheros añadidos, copiados y renombrados,
   mientras que los ficheros eliminados y las fuentes renombradas se
 
 En contraste, con la cohesión de MQ con el control de revisiones
 distribuidos y los parches, resulta más sencillo aislar su trabajo.
-Sus parches viven encima de la historia de revisiones normales, y
+Sus parches viven encima de el historial de revisiones normales, y
 puede hacer que ellos desaparezcan o reaparezcan cuando lo desee.  Si
 no le gusta un parche, puede desecharlo.  Si un parche no satisface
 todo lo que usted desea, puede arreglarlo---tantas veces como lo

File es/template.tex

 Podríamos haber incluído el texto del fichero plantilla directamente
 en el fichero de estilo encerrando entre comillas y reemplazando las
 nuevas líneas con secuencias ``\verb!\n!'', pero haría muy difícil de
-leer el archivo de estilos.  La facilidad para leer es importante
+leer el fichero de estilos.  La facilidad para leer es importante
 cuando está decidiendo si un texto pertenece a un fichero de estilo o
 a un fichero de plantilla incluído en el estilo.  Si el fichero de
 estilo luce muy grande o complicado, si inserta una pieza de texto

File es/tour-basic.tex

 repositorio y en el repositorio que clonamos.
 
 Cada repositorio Mercurial está completo, es autocontenido e
-independiente. Contiene su propia copia de los ficheros y la historia
+independiente. Contiene su propia copia de los ficheros y el historial
 de un proyecto. Un repositorio clonado recuerda la ubicación de la que
 fue clonado, pero no se comunica con ese repositorio, ni con ningún
 otro, a menos que usted le indique que lo haga.
 el repositorio ``real'', y todos los ficheros y directorios que
 coexisten con él están en el \emph{directorio de trabajo}. Una forma
 sencilla de recordar esta distinción es que el \emph{repositorio}
-% TODO unificar con Igor, si historia o historial
 contiene el \emph{historial} de su proyecto, mientras que el
 \emph{directorio de trabajo} contiene una \emph{instantánea} de su
 proyecto en un punto particular del historial.

File es/tour-merge.tex

 \command{kdiff3} ejecutándose, en la
 figura~\ref{fig:tour-merge:kdiff3}.  El tipo de fusión que la
 herramienta hace se conoce como \emph{fusión de tres vías}, porque hay
-tres versiones diferentes del archivo en que estamos interesados.
+tres versiones diferentes del fichero en que estamos interesados.
 Debido a esto la herramienta divide la parte superior de la ventana en
 tres paneles.
 \begin{itemize}
 diferencian en las plataformas para las que están disponibles, y en
 sus fortalezas y debilidades particulares. La mayoría están afinadas
 para fusionar texto plano, mientras que otras están pensadas para
-formatos de archivos especializados (generalmente XML).
+formatos de ficheros especializados (generalmente XML).
 
 % TODO traduje "worked" como "real"
 \subsection{Un ejemplo real}
 tiene unas características poderosas que le ayudarán a isolar las
 fuentes de los problemas, y a dar cuenta de ellas apropiadamente.
 
-\section{Borrar la historia local}
+\section{Borrar el historial local}
 
 \subsection{La consignación accidental}
 
 el conjunto de cambios.  Uso la orden \hgcmd{rollback}, y Mercurial
 hace desaparecer el último conjunto de cambios.
 \interaction{rollback.rollback}
-El conjunto de cambios ya no está en la historia del repositorio, y el
+El conjunto de cambios ya no está en el historial del repositorio, y el
 directorio de trabajo cree que el fichero \filename{a} ha sido
 modificado.  La consignación y el roll back dejaron el directorio de
 trabajo exactamente como estaba antes de la consignación; el conjunto
 El valor de \hgcmd{rollback} se anula cuando ha publicado sus cambios
 a otro repositorio.  Un cambio desaparece totalmente al hacer roll back,
 pero \emph{solamente} en el repositorio en el cual aplica
-\hgcmd{rollback}.  Debido a que un roll back elimina la historia,
+\hgcmd{rollback}.  Debido a que un roll back elimina el historial,
 no hay forma de que la desaparición de un cambio se propague entre
 repositorios.
 
 parte de un conjunto de cambios a mano.
 
 Antes de leer esta sección, hay algo para tener en cuenta: la orden
-\hgcmd{backout} deshace cambios \emph{adicionando} a la historia, sin
+\hgcmd{backout} deshace cambios \emph{adicionando} a el historial, sin
 modificar o borrar.  Es la herramienta correcta si está arreglando
 fallos, pero no si está tratando de deshacer algún cambio que tiene
 consecuencias catastróficas.  Para tratar con esos, vea la sección~\ref{sec:undo:aaaiiieee}.
 \subsection{Retroceder un conjunto de cambios}
 
 La orden \hgcmd{backout} le permite ``deshacer'' los efectos de todo
-un conjunto de cambios de forma automatizada.  Dado que la historia de
+un conjunto de cambios de forma automatizada.  Dado que el historial de
 Mercurial es inmutable, esta orden \emph{no} se deshace del conjunto
 de cambios que usted desea deshacer.  En cambio, crea un nuevo
 conjunto de cambios que \emph{reversa} el conjunto de cambios que
 Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es
 un hijo del conjunto de cambios que retrocedimos. Es más sencillo de
 ver en la figura~\ref{fig:undo:backout}, que presenta una vista
-gráfica de la historia de cambios.  Como puede ver, la historia es
-bonita y lineal.
+gráfica de el historial de cambios.  Como puede ver, el historial es
+bonito y lineal.
 
 \begin{figure}[htb]
   \centering
 presentes, pero no el segundo.
 \interaction{backout.non-tip.cat}
 
-Como lo muestra la historia gráfica en la
+Como lo muestra el historial gráfico en la
 figura~\ref{fig:undo:backout-non-tip}, Mercurial realmente consigna
 \emph{dos} cambios en estas situaciones (los nodos encerrados en una
 caja son aquellos que Mercurial consigna automaticamente).  Antes de
 \end{figure}
 
 El resultado es que usted termina ``donde estaba'', solamente con un
-poco de historia adicional que deshace el efecto de un conjunto de
+poco de historial adicional que deshace el efecto de un conjunto de
 cambios que usted quería evitar.
 
 \subsubsection{Use siempre la opción \hgopt{backout}{--merge}}
 orden \hgcmd{backout} fue muy explícita diciéndolo.
 \interaction{backout.manual.log}
 
-De nuevo, es más sencillo lo que pasó viendo una gráfica de la
-historia de revisiones, en la figura~\ref{fig:undo:backout-manual}.
+De nuevo, es más sencillo lo que pasó viendo una gráfica del
+historial de revisiones, en la figura~\ref{fig:undo:backout-manual}.
 Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un
 cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al
 repositorio (el cambio que consignó está encerrado en una caja).
 Reflexionemos acerca de lo que esperamos ver como contenidos de
 \filename{myfile}.  El primer cambio debería estar presente, porque
 nunca le hicimos retroceso.  El segundo cambio debió desaparecer,
-puesto que es el que retrocedimos.  Dado que la gráfica de la historia
+puesto que es el que retrocedimos.  Dado que la gráfica de el historial
 muestra que el tercer camlio es una cabeza separada, \emph{no}
 esperamos ver el tercer cambio presente en \filename{myfile}.
 \interaction{backout.manual.cat}
 Para que el tercer cambio esté en el fichero, hacemos una fusión usual
 de las dos cabezas.
 \interaction{backout.manual.merge}
-Después de eso, la historia gráfica de nuestro repositorio luce como
+Después de eso, el historial gráfica de nuestro repositorio luce como
 la figura~\ref{fig:undo:backout-manual-merge}.
 
 \begin{figure}[htb]
 retrocediendo y la punta actual.
 
 Si está retrocediendo un conjunto de cambios que está a unas ~100
-atrás en su historia del proyecto, las posibilidades de que una orden
+atrás en su historial del proyecto, las posibilidades de que una orden
 \command{patch} sea capaz de ser aplicada a un diff reverso,
 claramente no son altas, porque los cambios que intervienen podrían
 ``no coincidir con el contexto'' que \command{patch} usa  para
 colocarse una bolsa de papel desechable en su cabeza), permítame
 discutir primero unas aproximaciones que probablemente no funcionen.
 
-Dado que Mercurial trata de forma acumulativa la historia---cada
-cambio se coloca encima de todos los cambios que leo
-preceden---usualmente usted no puede hacer que unos cambios desastros
+Dado que Mercurial trata de forma acumulativa al historial---cada
+cambio se coloca encima de todos los cambios que le
+preceden---usualmente usted no puede hacer que unos cambios desastrosos
 desaparezcan. La única excepción es cuando usted ha acabado de
 consignar un cambio y este no ha sido publicado o jalado en otro
 repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con
-seguridad, Como detallé en la sección~\ref{sec:undo:rollback}.
+seguridad, como detallé en la sección~\ref{sec:undo:rollback}.
 
 Después de que usted haya publicado un cambio en otro repositorio, usted
 \emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia
 
 Si ha consignado uno o más cambios \emph{después} del cambio que desea
 desaparecer, sus opciones son aún más reducidas. Mercurial no provee
-una forma de ``cabar un hueco'' en la historia, dejando los conjuntos
+una forma de ``cabar un hueco'' en el historial, dejando los conjuntos
 de cambios intactos.
 
 %Dejamos de traducir lo que viene a continuación, porque será
 búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al
 conjunto de cambios culpable.
 
-La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' de la
-historia de revisiones de su proyecto para hacer una búsqueda
+La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' del
+historial de revisiones de su proyecto para hacer una búsqueda
 proporcional al \emph{logaritmo} del número de conjunto de cambios a
-revisar( el tipo de búsqueda que realiza se llama búsqueda
+revisar (el tipo de búsqueda que realiza se llama búsqueda
 binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de
-cambios tomará menos de 3 horas, incluso a diez minutos por prueba(La
+cambios tomará menos de 3 horas, incluso a diez minutos por prueba (La
 búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la
 última centena de conjuntos de cambios, tomará a lo sumo una
-hora(Apenas unas 7 pruebas).
+hora (Apenas unas 7 pruebas).
 
 La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
-de la historia de revisiones del proyecto con Mercurial, así que no
+de el historial de revisiones del proyecto con Mercurial, así que no
 hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
-repositorio.  Puede evitar ramas enteras de historia con un solo
+repositorio.  Puede evitar ramas enteras de historial con un solo
 sondeo.
 
 \subsection{Uso de la orden \hgcmd{bisect}}
 otro fallo puede enmascararlo(como se discutió anteriormente).
 
 Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
-meses de historia, solamente estaŕa adicionando unas pruebas contadas
+meses de historial, solamente estaŕa adicionando unas pruebas contadas
 para \hgcmd{bisect}, gracias al comportamiento logarítmico.
 
 %%% Local Variables: