FAQ de Mercurial

  • Enlace amigable (slug) de la revisión: FAQ_de_Mercurial
  • Título de la revisión: FAQ de Mercurial
  • Id de la revisión: 122895
  • Creada:
  • Creador: RickieesES
  • ¿Es la revisión actual? No
  • Comentario /* Cómo actúo ante "abort: push creates new remote heads!"? */

Contenido de la revisión

{{wiki.template('Traducción', [ "inglés", "Mercurial_FAQ", "en" ])}}

¿En qué se diferencia Mercurial de CVS?

  • "En mucho". Deberías leer y comprender lo básico de Mercurial antes de hacerte cargo de trabajo con Mercurial en el que tengas interés.
  • Los cambios en Mercurial son atómicos.
  • En Mercurial, el etiquetado es rápido y O(1).
  • Mercurial facilita a todos bifurcar el repositorio central (la orden es hg clone).
  • Con Mercurial tendrás un clon completo, totalmente armado y operacional del repositorio entero de Mozilla en tu disco duro. Puedes trabajar localmente y aplicarle cambios sin afectar a nadie más. Para promocionar los cambios al repositorio principal, usa hg push.
  • Las colas de Mercurial (inglés) pueden ayudarte a hacer malabarismos con los parches. Es como Quilt (inglés). La idea tras Quilt es ésta:

    Los scripts permiten manejar una serie de parches manteniendo un registro de los cambios que hace cada parche. Los parches pueden ser aplicados, des-aplicados, refrescados, etc.

    El concepto filosófico clave es que tu salida principal son parches. No archivos ".c", no archivos ".h", sino parches. Así que los parches son el objeto de primera categoría aquí.

  • Cuando CVS encuentra conflictos al fusionar, pone marcadores de conflicto en tu archivo. Cuando Mercurial encuentra conflictos al fusionar, lanza un programa de fusión (inglés). Esto es como un dolor de cervicales.
  • En muchos casos en los que CVS actúa por archivo o por directorio, Mercurial actúa por repositorio. Por ejemplo, un solo conjunto de cambios de Mercurial puede contener archivos a muchos archivos a lo largo del árbol.
  • Esperamos que Mercurial nos permita volver a pensar la manera en la que trabajamos. Los equipos e individuos deberían poder ramificar y fusionar mucho más fácilmente - sin abrir incidencias para el equipo técnico. La gente de fuera de la comunidad que sean desarrolladores experimentados deberían ser capaces de hacer cosas sorprendentes con esto. Las compañías que mantienen bifurcaciones de Mozilla deberían poder trabajar mejor, también. Todo está por ver, no obstante.

¿Cómo instalo Mercurial?

Si usas apt-get, emerge, port, o yum para instalar software, limítate a hacer lo normal. Si obtienes como resultado una versión antigua (pre-1.0 -- compruébalo con hg version), puedes actualizarlo usando easy_install como sigue (usando apt-get en este ejemplo):

sudo apt-get install python-setuptools python-dev build-essential
sudo easy_install -U mercurial

En caso contrario, los paquetes binarios de Mercurial (inglés) están hechos para ti. Revisa también {{mediawiki.interwiki('wikimo', 'Mercurial_on_Windows', 'wikimo:Mercurial on Windows')}} (inglés).

Programa de fusión

Tras instalar, elige un programa de fusión (inglés). En serio. Hazlo ahora. Si no lo haces, Mercurial elegirá uno por ti y te lo plantará en tus narices cuando menos lo esperes.

Algo razonable para hacer es configurar <tt>ui.merge=internal:merge</tt> en el archivo de configuración de Mercurial (ver más abajo), lo que hace que Mercurial intente fusionar los cambios y añadir los marcadores de conflicto (al estilo CVS) a los archivos que no pueda fusionar.

Puedes ver la lista de conflictos de fusión buscando "merging ... failed!" en la salida de update.

Configuración

Deberías configurar Mercurial antes de descargar el código. Tu archivo de configuración de Mercurial (~/.hgrc) debería tener al menos la siguiente configuración:

[ui]
username = Tu Nombre Real <user@example.com>
merge = tu-programa-de-fusión

[diff]
git = 1

[defaults]
diff=-p -U 8

En Windows, estos valores se pueden añadir a <tt>C:\Archivos de Programa\Mercurial\Mercurial.ini</tt>. En los sistemas tipo Unix, debería estar en tu archivo <tt>$HOME/.hgrc</tt>.

Puedes configurar el editor a usar para los mensajes de fusión usando la opción <tt>editor</tt> en la sección <tt>{{mediawiki.external('ui')}}</tt> o estableciendo la variable de entorno <tt>EDITOR</tt>.

¿Cómo gestiona Mercurial los finales de línea?

La versión Windows de Mercurial no convierte automáticamente los finales de línea entre los estilos de Windows y Unix. Todos nuestros repositorios usan finales de línea Unix. Necesitamos una manera de solucionar esto en Windows, pero de momento no sabemos cómo.

(¿Qué tal si insertamos un control previo al commit que rechace los cambios que contienen CR con un mensaje de error informativo apropiado? Posiblemente querremos hacer excepciones para ciertos tipos de archivo (como poco, archivos binarios, por supuesto), pero podemos ajustar el control según consideremos necesario. Mercurial 1.0 añade un control estándar para esto en la extensión win32text que podríamos usar/adaptar --jwatt).

¿Cómo puedo...?

¿Cómo puedo descargar Mozilla?

El desarrollo principal (trunk) de Mozilla 2 está ubicado en http://hg.mozilla.org/mozilla-central/ . Revisa Código fuente de Mozilla (Mercurial) para instrucciones sobre cómo descargar el código fuente de Mozilla 2 de Mercurial.

¿Cómo puedo editar y actualizar archivos?

Puedes editar archivos a voluntad en el directorio de trabajo, exactamente igual que con CVS.

La orden común para actualizar un árbol es:

hg pull -u

No es posible actualizar sólo un directorio; tienes que actualizar el árbol entero.

¿Cómo detecto cambios y aplico parches en archivos?

  • hg diff muestra las diferencias del árbol completo por defecto. Usa hg diff <dir> para ver las diferencias sólo del directorio dado. No olvides hacer hg add de cualquier archivo nuevo que estés añadiendo antes de generar el parche.
  • Si estás cambiando archivos binarios o renombrando archivos puedes querer usar parches al estilo git con hg diff -g para conservar ese tipo de información en el parche.
  • Al aplicar un parche generado por Mercurial, usa patch -p1, no patch -p0 (esto se debe a un fallo de la salida del diff de Mercurial — se refiere a los directorios ficticios "a" y "b". No preguntes).
  • Si tienes un parche de estilo git con renombrados o cambios binarios puedes usar hg import --no-commit para aplicar el parche a tu árbol o usar hg qimport para importar el parche en mq.

Las opciones de diff preferidas son hg diff -p -U 8 que incluye 8 líneas de contexto y muestra la función relevante del bloque. Puedes convertir estas opciones en predeterminadas en el archivo de configuración de Mercurial.

¿Cómo aplico cambios?

Configuración necesaria

Antes de aplicar ningún cambio, añade estas líneas a tu archivo ~/.hgrc:

[ui]
username = Tu nombre <tu.email@example.com>

Para subir los cambios a mozilla-central y otros repositorios alojados en mozilla tienes que tener acceso de escritura (committer), y debes editar el archivo (tu-raíz-hg-local)/.hg/hgrc (observa que éste NO es tu ~/.hgrc) para añadir esta línea:

[paths]
default = http://hg.mozilla.org/mozilla-central/
default-push = ssh://hg.mozilla.org/mozilla-central/

También tienes que decirle a SSH qué nombre de usuario utilizar al conectar con hg.mozilla.org. Éste debería ser el nombre de usuario asociado a tu cuenta LDAP en Mozilla. Puedes hacer esto bien complicando ligeramente la ruta de aplicación por defecto, o default-push, (convirtiéndola en user@host.name@hg.mozilla.org) o bien añadiendo líneas a tu ~/.ssh/config:

Host hg.mozilla.org
User usuario@host.dominio

Comprueba lo que vas a aplicar

A continuación, para comprobar si realmente vas a aplicar los cambios que quieres aplicar (especialmente importante al hacer fusiones y otros cambios complejos):

hg status
hg diff

<tt>status</tt> muestra los archivos que han cambiado en tu directorio de trabajo comparado con lo que hay en tu repositorio (las revisiones padre, que puedes ver usando <tt>hg parents</tt>). <tt>hg diff</tt> muestra los cambios reales en esos archivos, como diffs unificados. Puedes añadir la opción -U8 para ver más contexto.

Aplica al repositorio local

Como siguiente paso, aplicarás tus cambios a tu repositorio local:

hg commit

Esto aplica los cambios informado por hg status. Puedes limitar la aplicación a archivos o directorios específicos usando hg commit nombres_de_archivo. Puedes aplicar los cambios en nombre de alguna otra persona usando hg commit -u "Algún otro <algun_otro@example.com>". Revisa hg help commit para obtener más detalles.

Comprueba lo que vas a subir

Antes de que subas (push), probablemente quieras comprobar qué conjuntos de cambios se subirán. Puedes hacer esto usando la orden outgoing:

hg outgoing

Esto te dará una lista de conjuntos de cambio que se subirán al repositorio remoto predeterminado. Añade un argumento de repositorio para ver los cambios salientes (outgoing) en ese otro repositorio.

Subir al repositorio central

Para subir esos cambios hasta el repositorio central:

hg push

Obtendrás un mensaje de error sin importancia cada vez que subas:

remote: Could not chdir to home directory : No such file or directory

Ignóralo sin más.

¿Cómo actúo ante "abort: push creates new remote heads!"?

Hagas lo que hagas, no hagas 'push -f' como sugiere el mensaje (probablemente falle de todas formas, pero ni lo intentes).

Alguien ha subido nuevos cambios desde tu última descarga. A continuación has aplicado tu parche localmente y estás intentando subir ese cambio al repositorio principal, el cual tiene un último cambio distinto de aquél desde el que comenzaste.

Hay dos cosas que puedes hacer. La más sencilla es fusionar tus cambios: ejecuta hg pull, luego hg merge. Resuelve cualquier conflicto que surja, y luego aplica la fusión resultante: hg commit -m "Merge commit for bug 123456". Luego haz hg push normalmente. Esto tiene el desafortunado efecto colateral de dejar un feo cambio por fusión en el historial de revisiones y, lo que es peor, hará tu parche más difícil de retrotraer si tuviste que resolver conflictos.

Sin embargo, es lo más sencillo, y es muy seguro. Hay otra manera de afrontar el problema, pero es considerablemente más arcana -- hay un arreglo/reemplazo en progreso.

{{template.Warning("Esta aproximación funciona casi bien, pero hay algunos informes de parches que han sido tragados en varias ocasiones. Toma precauciones para hacer copias de tus parches (quizá obteniendo un diff: hg log -p -r 12345 para mostrar el parche de la revisión 12345) hasta que estés seguro de que las cosas funcionan como esperas.")}}

Lo más avanzado que puedes hacer es importar el cambio en mq, extraerlo de la cola, actualizar, y volver a aplicarlo de nuevo antes de subirlo:

% hg log -l 5
415[tip]   d1accb6ee840   2008-04-30 09:57 -0700   vladimir
  b=430873; fast path drawImage with a canvas as source
414   3a3ecbb4873e   2008-04-30 09:55 -0700   vladimir
  cvs sync
% hg qimport -r 415
% hg qtop
415.diff
% hg qpop
Patch queue now empty
% hg pull -u
... varios mensajes de descarga/actualización ...
% hg qpush
applying 415.diff
Now at: 415.diff
Corrige los conflictos según sea necesario; si has corregido alguno, ejecuta hg qrefresh primero
% hg qrm -r 415.diff
qrm -r significa "elimina este parche de mi cola, pero conserva la revisión"
% hg log -l 5
verifica que el registro tiene buena pinta, con tu cambio arriba del todo
% hg push

Si ya has usado mq para gestionar tus parches, asegúrate de que descargas/actualizas justo antes de aplicar y subir tu parche. Si tienes problemas con lo anterior, no hay nada malo en hacer una fusión simple como se ha descrito anteriormente.

How do I see what these commands will do before I do them?

If you want to see what hg commit will commit, run hg diff first.

If you want to see what hg push will push, run hg outgoing first.

If you want to see what hg pull will pull, run hg incoming first.

These pairs of commands all take similar arguments, for good reason. These are a good idea to use all the time when you're learning mercurial. And even once you're an expert, always doing outgoing before push is a good idea.

How can I customize the format of the patches Mercurial creates?

Edit your ~/.hgrc file and add some lines like these:

[defaults]
diff=-U 8 -p
qdiff=-U 8

[diff]
git=true

The {{mediawiki.external('defaults')}} section affects the default output of the hg diff and hg qdiff commands. The options behave the same as they would on the command line. Try hg help diff for more info.

The {{mediawiki.external('diff')}} section affects all patches generated by Mercurial, even those generated for Mercurial's internal use. You need to be a lot more careful with this, but git=true is recommended. Without it, Mercurial cannot diff binary files and does not track the execute mode bit.

Backing out changes

Reverting the whole tree to a known-good revision

It's easy, like using a sledgehammer is easy. But this is usually overkill.

$ hg pull -u
$ hg revert --all -r a0193d83c208       # use your known-good revision id here
$ hg commit                             # be kind, include the revision id in your commit message
$ hg push

There's a more precise alternative:

Backing out a single changeset

Suppose changeset <tt>f8f4360bf155</tt> broke something.

$ hg pull -u
$ hg backout f8f4360bf155               # use the revision id of the bad change here

This creates and commits a new changeset that reverts all the changes in that revision.

If you see this message:

the backout changeset is a new head - do not forget to merge

That means you need to merge, because your history now looks like this:

  YOU ---> o  9123b7791b52 - Kaitlin Jones <kaitlin@example.net> - Backed out changeset f8f4360bf155
           | 
TRUNK ---> | o  4e5bfb83643f - Simon Montagu <smontagu@example.org> - imported patch 435856
           | | 
           | o  6ee23de41631 - Phil Ringnalda <philringnalda@example.com> - Bug 438526 - Opening links w
           | | 
           | o  22baa05d0e8a - Robert O'Callahan <robert@example.org> - Remove DOM testcase from exclusi
           | | 
           | o  c1aec2094f7e - Robert Longson <longsonr@example.com> - Bug 437448. New-style nsSVGString
           | | 
           | o  306726089e22 - Robert Longson <longsonr@example.com> - Bug 437448. New-style nsSVGString
           | | 
           | o  ba9b9a7c52a5 - Robert Longson <longsonr@example.com> - Bug 437448. New-style nsSVGString
           |/
           o  f8f4360bf155 - Robert O'Callahan <robert@example.org> - Bug 421436. Remove hack that gives
           |
           ⋮ (the past)

Your backout changeset is based on an old revision. It doesn't contain more recent changes.

Handle this like any other merge. If you've never done a merge before, get help. (It could be trivial or it could be a huge headache. There's plenty about merging elsewhere in this FAQ.)

Help

Help, I can't push!

If you're trying to push, and you can't, first try this:

$ ssh hg.mozilla.org

If you see output like:

Permission denied (publickey,gssapi-with-mic).

it may have the following reasons:

If you see output like:

You are not allowed to use this system, go away!

then you need to file a bug in mozilla.org:Server Operations.

You should expect the ssh command to disconnect you immediately, since you're not supposed to have shell access. It may give the output:

Could not chdir to home directory : No such file or directory

which is harmless (although some people see it and some people don't).

If you see output like:

ssl required

then you need to configure your default-push correctly.

Things that have changed

  • Bonsai is replaced by the Hg web viewer. This lacks some bonsai features that would be nice, including mark, line-number anchors, and graphs. There are some terminology differences:

bonsai blame == hg annotate
bonsai log == hg revisions
also you can browse the repository using the "manifest" link.

  • There's no Bugzilla integration for Mercurial.
{{ wiki.languages( { "en": "en/Mercurial_FAQ" } ) }}

Fuente de la revisión

<p>{{wiki.template('Traducción', [ "inglés", "Mercurial_FAQ", "en" ])}}
</p>
<h3 name=".C2.BFEn_qu.C3.A9_se_diferencia_Mercurial_de_CVS.3F"> ¿En qué se diferencia Mercurial de CVS? </h3>
<ul><li> "En mucho". Deberías leer y comprender <a href="es/Lo_b%c3%a1sico_de_Mercurial">lo básico de Mercurial</a> antes de hacerte cargo de trabajo con Mercurial en el que tengas interés.
</li></ul>
<ul><li> Los cambios en Mercurial son atómicos.
</li></ul>
<ul><li> En Mercurial, el etiquetado es rápido y O(1).
</li></ul>
<ul><li> Mercurial facilita a todos bifurcar el repositorio central (la orden es <code>hg clone</code>).
</li></ul>
<ul><li> Mercurial hace que ramificar sea rápido y fácil y mantiene la fusión muy coherente (ver <a href="es/Publicar_clones_en_Mercurial">Publicar clones en Mercurial</a>).
</li></ul>
<ul><li> Con Mercurial tendrás un <i>clon</i> completo, totalmente armado y operacional del repositorio entero de Mozilla en tu disco duro. Puedes trabajar localmente y aplicarle cambios sin afectar a nadie más. Para promocionar los cambios al repositorio principal, usa <code>hg push</code>.
</li></ul>
<ul><li> <a class="external" href="http://hgbook.red-bean.com/hgbookch12.html#x16-26700012">Las colas de Mercurial (inglés)</a> pueden ayudarte a hacer malabarismos con los parches. Es como <a class="external" href="http://savannah.nongnu.org/projects/quilt">Quilt (inglés)</a>. La idea tras Quilt es ésta:  <blockquote><p>Los scripts permiten manejar una serie de parches manteniendo un registro de los cambios que hace cada parche. Los parches pueden ser aplicados, des-aplicados, refrescados, etc.</p> <p>El concepto filosófico clave es que tu salida principal son parches. No archivos ".c", no archivos ".h", sino parches. Así que los parches son el objeto de primera categoría aquí.</p></blockquote>
</li></ul>
<ul><li> Cuando CVS encuentra conflictos al fusionar, pone marcadores de conflicto en tu archivo. Cuando Mercurial encuentra conflictos al fusionar, lanza un <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram">programa de fusión (inglés)</a>. Esto es como un dolor de cervicales.
</li></ul>
<ul><li> En muchos casos en los que CVS actúa por archivo o por directorio, Mercurial actúa por repositorio. Por ejemplo, un solo conjunto de cambios de Mercurial puede contener archivos a muchos archivos a lo largo del árbol.
</li></ul>
<ul><li> <b>Esperamos que Mercurial nos permita volver a pensar la manera en la que trabajamos</b>. Los equipos e individuos deberían poder ramificar y fusionar mucho más fácilmente - sin abrir incidencias para el equipo técnico. La gente de fuera de la comunidad que sean desarrolladores experimentados deberían ser capaces de hacer cosas sorprendentes con esto. Las compañías que mantienen bifurcaciones de Mozilla deberían poder trabajar mejor, también. Todo está por ver, no obstante.
</li></ul>
<h3 name=".C2.BFC.C3.B3mo_instalo_Mercurial.3F"> ¿Cómo instalo Mercurial? </h3>
<p>Si usas <code>apt-get</code>, <code>emerge</code>, <code>port</code>, o <code>yum</code> para instalar software, limítate a hacer lo normal. Si obtienes como resultado una versión antigua (pre-1.0 -- compruébalo con <code>hg version</code>), puedes actualizarlo usando <code>easy_install</code> como sigue (usando <code>apt-get</code> en este ejemplo):
</p>
<pre class="eval">sudo apt-get install python-setuptools python-dev build-essential
sudo easy_install -U mercurial
</pre>
<p>En caso contrario, los <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages">paquetes binarios de Mercurial (inglés)</a> están hechos para ti. Revisa también {{mediawiki.interwiki('wikimo', 'Mercurial_on_Windows', 'wikimo:Mercurial on Windows')}} (inglés).
</p>
<h4 name="Programa_de_fusi.C3.B3n"> Programa de fusión </h4>
<p>Tras instalar, <b>elige un <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram">programa de fusión (inglés)</a></b>. En serio. Hazlo ahora. Si no lo haces, Mercurial elegirá uno por ti y te lo plantará en tus narices cuando menos lo esperes.
</p><p>Algo razonable para hacer es configurar <tt>ui.merge=internal:merge</tt> en el archivo de configuración de Mercurial (ver más abajo), lo que hace que Mercurial intente fusionar los cambios y añadir los marcadores de conflicto (al estilo CVS) a los archivos que no pueda fusionar.
</p><p>Puedes ver la lista de conflictos de fusión buscando "merging ... failed!" en la salida de update.
</p>
<h4 name="Configuraci.C3.B3n"> Configuración </h4>
<p>Deberías configurar Mercurial antes de descargar el código. Tu archivo de configuración de Mercurial (<code>~/.hgrc</code>) debería tener al menos la siguiente configuración:
</p>
<pre class="eval">[ui]
username = Tu Nombre Real &lt;user@example.com&gt;
merge = <i>tu-programa-de-fusión</i>

[diff]
git = 1

[defaults]
diff=-p -U 8
</pre>
<p>En Windows, estos valores se pueden añadir a <tt>C:\Archivos de Programa\Mercurial\Mercurial.ini</tt>. En los sistemas tipo Unix, debería estar en tu archivo <tt>$HOME/.hgrc</tt>.
</p><p>Puedes configurar el editor a usar para los mensajes de fusión usando la opción <tt>editor</tt> en la sección <tt>{{mediawiki.external('ui')}}</tt> o estableciendo la variable de entorno <tt>EDITOR</tt>.
</p>
<h3 name=".C2.BFC.C3.B3mo_gestiona_Mercurial_los_finales_de_l.C3.ADnea.3F"> ¿Cómo gestiona Mercurial los finales de línea? </h3>
<p>La versión Windows de Mercurial no convierte automáticamente los finales de línea entre los estilos de Windows y Unix. Todos nuestros repositorios usan finales de línea Unix. Necesitamos una manera de solucionar esto en Windows, pero de momento no sabemos cómo.
</p><p>(¿Qué tal si insertamos un control previo al commit que rechace los cambios que contienen CR con un mensaje de error informativo apropiado? Posiblemente querremos hacer excepciones para ciertos tipos de archivo (como poco, archivos binarios, por supuesto), pero podemos ajustar el control según consideremos necesario. Mercurial 1.0 añade un control estándar para esto en la extensión win32text que podríamos usar/adaptar --jwatt).
</p>
<h2 name=".C2.BFC.C3.B3mo_puedo....3F"> ¿Cómo puedo...? </h2>
<h3 name=".C2.BFC.C3.B3mo_puedo_descargar_Mozilla.3F"> ¿Cómo puedo descargar Mozilla? </h3>
<p>El desarrollo principal (trunk) de Mozilla 2 está ubicado en http://hg.mozilla.org/mozilla-central/ . Revisa <a href="es/C%c3%b3digo_fuente_de_Mozilla_(Mercurial)">Código fuente de Mozilla (Mercurial)</a> para instrucciones sobre cómo descargar el código fuente de Mozilla 2 de Mercurial.
</p>
<h3 name=".C2.BFC.C3.B3mo_puedo_editar_y_actualizar_archivos.3F"> ¿Cómo puedo editar y actualizar archivos? </h3>
<p>Puedes editar archivos a voluntad en el directorio de trabajo, exactamente igual que con CVS.
</p><p>La orden común para actualizar un árbol es:
</p>
<pre class="eval">hg pull -u
</pre>
<p>No es posible actualizar sólo un directorio; tienes que actualizar el árbol entero.
</p>
<h3 name=".C2.BFC.C3.B3mo_detecto_cambios_y_aplico_parches_en_archivos.3F"> ¿Cómo detecto cambios y aplico parches en archivos? </h3>
<ul><li> <code>hg diff</code> muestra las diferencias del árbol completo por defecto. Usa <code>hg diff &lt;dir&gt;</code> para ver las diferencias sólo del directorio dado. No olvides hacer <code>hg add</code> de cualquier archivo nuevo que estés añadiendo antes de generar el parche.
</li></ul>
<ul><li> Si estás cambiando archivos binarios o renombrando archivos puedes querer usar parches al estilo git con <code>hg diff -g</code> para conservar ese tipo de información en el parche.
</li></ul>
<ul><li> Al aplicar un parche generado por Mercurial, usa <code>patch -p1</code>, no <code>patch -p0</code>   (esto se debe a un fallo de la salida del diff de Mercurial — se refiere a los directorios ficticios "a" y "b". No preguntes).
</li></ul>
<ul><li> Si tienes un parche de estilo git con renombrados o cambios binarios puedes usar <code>hg import --no-commit</code> para aplicar el parche a tu árbol o usar <code>hg qimport</code> para importar el parche en mq.
</li></ul>
<p>Las opciones de diff preferidas son <code>hg diff -p -U 8</code> que incluye 8 líneas de contexto y muestra la función relevante del bloque. Puedes convertir estas opciones en predeterminadas en el <a href="es/Mercurial#Configuraci.C3.B3n">archivo de configuración de Mercurial</a>.
</p>
<h3 name=".C2.BFC.C3.B3mo_aplico_cambios.3F"> ¿Cómo aplico cambios? </h3>
<h4 name="Configuraci.C3.B3n_necesaria"> Configuración necesaria </h4>
<p>Antes de aplicar ningún cambio, añade estas líneas a tu archivo <code>~/.hgrc</code>:
</p>
<pre class="eval">[ui]
username = Tu nombre &lt;tu.email@example.com&gt;
</pre>
<p>Para subir los cambios a <a href="es/Mozilla-central">mozilla-central</a> y otros repositorios alojados en mozilla tienes que tener acceso de escritura (committer), y debes editar el archivo <code><i>(tu-raíz-hg-local)</i>/.hg/hgrc</code> (observa que éste <strong>NO</strong> es tu <code>~/.hgrc</code>) para añadir esta línea:
</p>
<pre class="eval">[paths]
default = <span class="plain">http://hg.mozilla.org/mozilla-central/</span>
<b>default-push = <span class="plain">ssh://hg.mozilla.org/mozilla-central/</span></b>
</pre>
<p>También tienes que decirle a SSH qué nombre de usuario utilizar al conectar con hg.mozilla.org. Éste debería ser el nombre de usuario asociado a tu cuenta LDAP en Mozilla. Puedes hacer esto bien complicando ligeramente la ruta de aplicación por defecto, o default-push, (convirtiéndola en user@host.name@hg.mozilla.org) o bien añadiendo líneas a tu ~/.ssh/config:
</p>
<pre class="eval">Host hg.mozilla.org
User usuario@host.dominio
</pre>
<h4 name="Comprueba_lo_que_vas_a_aplicar"> Comprueba lo que vas a aplicar </h4>
<p>A continuación, para comprobar si realmente vas a aplicar los cambios que quieres aplicar (especialmente importante al hacer fusiones y otros cambios complejos):
</p>
<pre class="eval">hg status
hg diff
</pre>
<p><tt>status</tt> muestra los archivos que han cambiado en tu directorio de trabajo comparado con lo que hay en tu repositorio (las revisiones padre, que puedes ver usando <tt>hg parents</tt>). <tt>hg diff</tt> muestra los cambios reales en esos archivos, como diffs unificados. Puedes añadir la opción -U8 para ver más contexto.
</p>
<h4 name="Aplica_al_repositorio_local"> Aplica al repositorio local </h4>
<p>Como siguiente paso, aplicarás tus cambios <i>a tu repositorio local</i>:
</p>
<pre class="eval">hg commit
</pre>
<p>Esto aplica los cambios informado por <code>hg status</code>. Puedes limitar la aplicación a archivos o directorios específicos usando <code>hg commit <i>nombres_de_archivo</i></code>. Puedes aplicar los cambios en nombre de alguna otra persona usando <code>hg commit -u "Algún otro &lt;algun_otro@example.com&gt;"</code>. Revisa <code>hg help commit</code> para obtener más detalles.
</p>
<h4 name="Comprueba_lo_que_vas_a_subir"> Comprueba lo que vas a subir </h4>
<p>Antes de que subas (push), probablemente quieras comprobar qué conjuntos de cambios se subirán. Puedes hacer esto usando la orden <code>outgoing</code>:
</p>
<pre class="eval">hg outgoing
</pre>
<p>Esto te dará una lista de conjuntos de cambio que se subirán al repositorio remoto predeterminado. Añade un argumento de repositorio para ver los cambios salientes (outgoing) en ese otro repositorio.
</p>
<h4 name="Subir_al_repositorio_central"> Subir al repositorio central </h4>
<p>Para subir esos cambios hasta el repositorio central:
</p>
<pre class="eval">hg push
</pre>
<p>Obtendrás un mensaje de error sin importancia cada vez que subas:
</p>
<pre class="eval">remote: Could not chdir to home directory : No such file or directory
</pre>
<p>Ignóralo sin más.
</p>
<h3 name=".C2.BFC.C3.B3mo_act.C3.BAo_ante_.22abort:_push_creates_new_remote_heads.21.22.3F"> ¿Cómo actúo ante "abort: push creates new remote heads!"? </h3>
<p>Hagas lo que hagas, no hagas 'push -f' como sugiere el mensaje (probablemente falle de todas formas, pero ni lo intentes).
</p><p>Alguien ha subido nuevos cambios desde tu última descarga. A continuación has aplicado tu parche localmente y estás intentando subir ese cambio al repositorio principal, el cual tiene un último cambio distinto de aquél desde el que comenzaste.
</p><p>Hay dos cosas que puedes hacer. La más sencilla es fusionar tus cambios: ejecuta hg pull, luego hg merge. Resuelve cualquier conflicto que surja, y luego aplica la fusión resultante: hg commit -m "Merge commit for bug 123456".  Luego haz hg push normalmente. Esto tiene el desafortunado efecto colateral de dejar un feo cambio por fusión en el historial de revisiones y, lo que es peor, hará tu parche más difícil de retrotraer si tuviste que resolver conflictos.
</p><p>Sin embargo, es lo más sencillo, y es muy seguro. Hay otra manera de afrontar el problema, pero es considerablemente más arcana -- hay un arreglo/reemplazo en progreso.
</p><p>{{template.Warning("Esta aproximación funciona casi bien, pero hay algunos informes de parches que han sido tragados en varias ocasiones. Toma precauciones para hacer copias de tus parches (quizá obteniendo un diff: hg log -p -r 12345 para mostrar el parche de la revisión 12345) hasta que estés seguro de que las cosas funcionan como esperas.")}}
</p><p>Lo más avanzado que puedes hacer es importar el cambio en <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension">mq</a>, extraerlo de la cola, actualizar, y volver a aplicarlo de nuevo antes de subirlo:
</p>
<pre class="eval">% <b>hg log -l 5</b>
415[tip]   d1accb6ee840   2008-04-30 09:57 -0700   vladimir
  b=430873; fast path drawImage with a canvas as source
414   3a3ecbb4873e   2008-04-30 09:55 -0700   vladimir
  cvs sync
% <b>hg qimport -r 415</b>
% <b>hg qtop</b>
415.diff
% <b>hg qpop</b>
Patch queue now empty
% <b>hg pull -u</b>
<i>... varios mensajes de descarga/actualización ...</i>
% <b>hg qpush</b>
applying 415.diff
Now at: 415.diff
<i>Corrige los conflictos según sea necesario; si has corregido alguno, ejecuta hg qrefresh primero</i>
% <b>hg qrm -r 415.diff</b>
<i>qrm -r significa "elimina este parche de mi cola, pero conserva la revisión"</i>
% <b>hg log -l 5</b>
<i>verifica que el registro tiene buena pinta, con tu cambio arriba del todo</i>
% <b>hg push</b>
</pre>
<p>Si ya has usado mq para gestionar tus parches, asegúrate de que descargas/actualizas justo antes de aplicar y subir tu parche. Si tienes problemas con lo anterior, no hay nada malo en hacer una fusión simple como se ha descrito anteriormente.
</p>
<h3 name="How_do_I_see_what_these_commands_will_do_before_I_do_them.3F"> How do I see what these commands will do before I do them? </h3>
<p>If you want to see what <code>hg commit</code> will commit, run <code>hg diff</code> first.
</p><p>If you want to see what <code>hg push</code> will push, run <code>hg outgoing</code> first.
</p><p>If you want to see what <code>hg pull</code> will pull, run <code>hg incoming</code> first.
</p><p>These pairs of commands all take similar arguments, for good reason.  These are a good idea to use all the time when you're learning mercurial.  And even once you're an expert, always doing outgoing before push is a good idea.
</p>
<h3 name="How_can_I_customize_the_format_of_the_patches_Mercurial_creates.3F"> How can I customize the format of the patches Mercurial creates? </h3>
<p>Edit your <code>~/.hgrc</code> file and add some lines like these:
</p>
<pre class="eval">[defaults]
diff=-U 8 -p
qdiff=-U 8

[diff]
git=true
</pre>
<p>The <code>{{mediawiki.external('defaults')}}</code> section affects the default output of the <code>hg diff</code> and <code>hg qdiff</code> commands.  The options behave the same as they would on the command line.  Try <code>hg help diff</code> for more info.
</p><p>The <code>{{mediawiki.external('diff')}}</code> section affects all patches generated by Mercurial, even those generated for Mercurial's internal use.  You need to be a lot more careful with this, but <code>git=true</code> is recommended.  Without it, Mercurial cannot diff binary files and does not track the execute mode bit.
</p>
<h2 name="Backing_out_changes"> Backing out changes </h2>
<h3 name="Reverting_the_whole_tree_to_a_known-good_revision"> Reverting the whole tree to a known-good revision </h3>
<p>It's easy, like using a sledgehammer is easy.  But this is usually overkill.
</p>
<pre class="eval">$ hg pull -u
$ <b>hg revert --all -r a0193d83c208</b>       <i># use your known-good revision id here</i>
$ hg commit                             <i># be kind, include the revision id in your commit message</i>
$ hg push
</pre>
<p>There's a more precise alternative:
</p>
<h3 name="Backing_out_a_single_changeset"> Backing out a single changeset </h3>
<p>Suppose changeset <tt>f8f4360bf155</tt> broke something.
</p>
<pre class="eval">$ hg pull -u
$ <b>hg backout f8f4360bf155</b>               <i># use the revision id of the bad change here</i>
</pre>
<p>This creates and commits a new changeset that reverts all the changes in that revision.
</p><p>If you see this message:
</p>
<pre class="eval">the backout changeset is a new head - do not forget to merge
</pre>
<p>That means you need to merge, because your history now looks like this:
</p>
<pre class="eval">  <b>YOU</b> ---&gt; o  9123b7791b52 - Kaitlin Jones &lt;kaitlin@example.net&gt; - Backed out changeset f8f4360bf155
           | 
<b>TRUNK</b> ---&gt; | o  4e5bfb83643f - Simon Montagu &lt;smontagu@example.org&gt; - imported patch 435856
           | | 
           | o  6ee23de41631 - Phil Ringnalda &lt;philringnalda@example.com&gt; - Bug 438526 - Opening links w
           | | 
           | o  22baa05d0e8a - Robert O'Callahan &lt;robert@example.org&gt; - Remove DOM testcase from exclusi
           | | 
           | o  c1aec2094f7e - Robert Longson &lt;longsonr@example.com&gt; - Bug 437448. New-style nsSVGString
           | | 
           | o  306726089e22 - Robert Longson &lt;longsonr@example.com&gt; - Bug 437448. New-style nsSVGString
           | | 
           | o  ba9b9a7c52a5 - Robert Longson &lt;longsonr@example.com&gt; - Bug 437448. New-style nsSVGString
           |/
           o  f8f4360bf155 - Robert O'Callahan &lt;robert@example.org&gt; - Bug 421436. Remove hack that gives
           |
           ⋮ (the past)
</pre>
<p>Your backout changeset is based on an old revision.  It doesn't contain more recent changes.
</p><p>Handle this like any other merge.  If you've never done a merge before, get help.  (It could be trivial or it could be a huge headache.  There's plenty about merging elsewhere in this FAQ.)
</p>
<h2 name="Help"> Help </h2>
<h3 name="Help.2C_I_can.27t_push.21"> Help, I can't push! </h3>
<p>If you're trying to push, and you can't, first try this:
</p>
<pre class="eval">$ ssh hg.mozilla.org
</pre>
<p>If you see output like:
</p>
<pre class="eval">Permission denied (publickey,gssapi-with-mic).
</pre>
<p>it may have the following reasons:
</p>
<ul><li> you need to <a href="#How_do_I_check_stuff_in.3F">configure your username correctly</a>
</li><li> you don't have the correct private key in ~/.ssh
</li><li> you don't have an hg.mozilla.org account. (If you should have one, <a class="external" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org">file a bug</a> in mozilla.org:Server Operations.)
</li></ul>
<p>If you see output like:
</p>
<pre class="eval">You are not allowed to use this system, go away!
</pre>
<p>then you need to <a class="external" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org">file a bug</a> in mozilla.org:Server Operations.
</p><p>You should expect the ssh command to disconnect you immediately, since you're not supposed to have shell access.  It may give the output:
</p>
<pre class="eval">Could not chdir to home directory : No such file or directory
</pre>
<p>which is harmless (although some people see it and some people don't).
</p><p>If you see output like:
</p>
<pre class="eval">ssl required
</pre>
<p>then you need to <a href="#How_do_I_check_stuff_in.3F">configure your default-push correctly</a>.
</p>
<h2 name="Things_that_have_changed"> Things that have changed </h2>
<ul><li> Bonsai is replaced by the <a class="external" href="http://hg.mozilla.org/mozilla-central/">Hg web viewer</a>. This lacks some bonsai features that would be nice, including mark, line-number anchors, and graphs. There are some terminology differences:
</li></ul>
<p>bonsai blame == hg annotate<br>
bonsai log == hg revisions<br>
also you can browse the repository using the "manifest" link.
</p>
<ul><li> MXR for mozilla-central is <a class="external" href="http://mxr.mozilla.org/mozilla-central/">now available</a>.
</li></ul>
<ul><li> There's no Bugzilla integration for Mercurial.
</li></ul>
<ul><li> <a href="es/Mercurial%2f%2fDesired_Features">Mercurial/Desired Features</a>
</li></ul>
<div class="noinclude">
</div>
{{ wiki.languages( { "en": "en/Mercurial_FAQ" } ) }}
Revertir a esta revisión