mozilla

Revision 122891 of 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: 122891
  • Creada:
  • Creador: RickieesES
  • ¿Es la revisión actual? No
  • Comentario /* How can I check out Mozilla? */

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.

How can I edit and update files?

You can randomly edit files in the working directory, just like with CVS.

The common command to update a tree is:

hg pull -u

It is not possible to update only one directory; you have to update the entire tree.

How can I diff and patch files?

  • hg diff diffs the entire tree by default. Use hg diff <dir> to diff only the given directory. Don't forget to hg add any new files you are adding before generating the patch.
  • If you are changing binary files or renaming files you may want to use git style patches with hg diff -g to retain that sort of information in the patch.
  • When applying a patch generated by Mercurial, use patch -p1, not patch -p0. (This is due to a quirk of Mercurial diff output—it refers to fictional "a" and "b" directories. Don't ask.).
  • If you have a git style patch with renames and/or binary changes you can use hg import --no-commit to apply the patch to your tree or use hg qimport to import the patch to mq.

Preferred diff options are hg diff -p -U 8 which includes 8 lines of context and shows the relevant function for the block. You can make these options default in the Mercurial configuration file.

How do I check stuff in?

Required configuration

Before committing any changes, add these lines to your ~/.hgrc file:

[ui]
username = Your Name <your.email@example.com>

To push to mozilla-central and other mozilla-hosted repositories you have to have committer access, and you must edit the file (your-local-hg-root)/.hg/hgrc (note, this is NOT your ~/.hgrc) to add this line:

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

You also have to tell ssh what username to use when connecting to hg.mozilla.org. This should be the username associated with your Mozilla LDAP account. You can do this either by making the default-push path above more complicated (user@host.name@hg.mozilla.org) or by adding lines to your ~/.ssh/config :

Host hg.mozilla.org
User user@host.domain

Check what you're going to commit

Next, to check if you're really committing what you want to commit (especially important when doing merges or other trickier commits):

hg status
hg diff

<tt>status</tt> shows the files that have changed in your working directory compared to what's in your repository (the parent revisions, which you can see by using <tt>hg parents</tt>). <tt>hg diff</tt> shows the actual changes in those files, as unified diffs. You can add a -U8 option to see more context.

Commit to the local repository

As the next step, you will commit your changes to your local repository:

hg commit

This commits every change reported by hg status. You can limit the commit to specific files or directories using hg commit filenames. You can commit on behalf of someone else using hg commit -u "Someone Else <someone@example.com>". See hg help commit for more details.

Check what you're going to push

Before you push, you likely want to check what changesets will be pushed. You can do this using the outgoing command:

hg outgoing

This will give you a list of changesets that will be pushed to the default remote repository. Add a repository argument to see outgoing changesets for another repository.

Push to the central repository

To push those changes upstream to the central repository:

hg push

You'll get a bogus error message each time you push:

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

Just ignore it.

How do I deal with "abort: push creates new remote heads!"?

Whatever you do, don't do 'push -f' like the message suggests. (It'll probably fail anyway, but don't try it.)

Someone pushed new commits upstream since your last pull. You then committed your patch locally and are trying to push that commit upstream; that upstream has a different commit that you started from.

There are two things you can do. The simplest is to merge your commits: run hg pull, then hg merge. Fix up any conflicts, and then commit the merge: hg commit -m "Merge commit for bug 123456". Then hg push as normal. This has the unfortunate side effect of leaving an ugly minor merge commit in the revision history, and, worse, making your patch more difficult to back out if you had conflicts to fix up.

However, it is the simplest thing to do, and is very safe. There is another approach, but it's considerably more arcane -- a fix/replacement is in the works.

{{template.Warning("This next approach mostly works fine, but there have been reports of patches being eaten at various times. Take steps to back up your patch (perhaps by obtaining a diff: hg log -p -r 12345 to show the patch for rev 12345) until you\'re sure things work like you expect.")}}

The more advanced thing you can do is to import the commit into mq, pop it off the queue, update, and then commit it again before pushing:

% 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
... various pull/update messages ...
% hg qpush
applying 415.diff
Now at: 415.diff
Fix up conficts as necessary; if you fixed up any, run hg qrefresh first
% hg qrm -r 415.diff
qrm -r means "remove this patch from my queue, but keep the revision"
% hg log -l 5
verify that the log looks good, with your commit on top
% hg push

If you already use mq to manage your patches, then just make sure you pull/update right before committing and pushing your patch. If you have problems with the above, it's ok to just do a simple merge as described previously.

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="How_can_I_edit_and_update_files.3F"> How can I edit and update files? </h3>
<p>You can randomly edit files in the working directory, just like with CVS.
</p><p>The common command to update a tree is:
</p>
<pre class="eval">hg pull -u
</pre>
<p>It is not possible to update only one directory; you have to update the entire tree.
</p>
<h3 name="How_can_I_diff_and_patch_files.3F"> How can I diff and patch files? </h3>
<ul><li> <code>hg diff</code> diffs the entire tree by default.  Use <code>hg diff &lt;dir&gt;</code> to diff only the given directory. Don't forget to <code>hg add</code> any new files you are adding before generating the patch.
</li></ul>
<ul><li> If you are changing binary files or renaming files you may want to use git style patches with <code>hg diff -g</code> to retain that sort of information in the patch.
</li></ul>
<ul><li> When applying a patch generated by Mercurial, use <code>patch -p1</code>, not <code>patch -p0</code>.  (This is due to a quirk of Mercurial diff output—it refers to fictional "a" and "b" directories.  Don't ask.).
</li></ul>
<ul><li> If you have a git style patch with renames and/or binary changes you can use <code>hg import --no-commit</code> to apply the patch to your tree or use <code>hg qimport</code> to import the patch to mq.
</li></ul>
<p>Preferred diff options are <code>hg diff -p -U 8</code> which includes 8 lines of context and shows the relevant function for the block. You can make these options default in the <a href="es/Mercurial#Configuration">Mercurial configuration file</a>.
</p>
<h3 name="How_do_I_check_stuff_in.3F"> How do I check stuff in? </h3>
<h4 name="Required_configuration"> Required configuration </h4>
<p>Before committing any changes, add these lines to your <code>~/.hgrc</code> file:
</p>
<pre class="eval">[ui]
username = Your Name &lt;your.email@example.com&gt;
</pre>
<p>To push to <a href="es/Mozilla-central">mozilla-central</a> and other mozilla-hosted repositories you have to have committer access, and you must edit the file <code><i>(your-local-hg-root)</i>/.hg/hgrc</code> (note, this is <strong>NOT</strong> your <code>~/.hgrc</code>) to add this line:
</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>You also have to tell ssh what username to use when connecting to hg.mozilla.org.  This should be the username associated with your Mozilla LDAP account.  You can do this either by making the default-push path above more complicated (user@host.name@hg.mozilla.org) or by adding lines to your ~/.ssh/config :
</p>
<pre class="eval">Host hg.mozilla.org
User user@host.domain
</pre>
<h4 name="Check_what_you.27re_going_to_commit"> Check what you're going to commit </h4>
<p>Next, to check if you're really committing what you want to commit (especially important when doing merges or other trickier commits):
</p>
<pre class="eval">hg status
hg diff
</pre>
<p><tt>status</tt> shows the files that have changed in your working directory compared to what's in your repository (the parent revisions, which you can see by using <tt>hg parents</tt>). <tt>hg diff</tt> shows the actual changes in those files, as unified diffs. You can add a -U8 option to see more context.
</p>
<h4 name="Commit_to_the_local_repository"> Commit to the local repository </h4>
<p>As the next step, you will commit your changes <i>to your local repository</i>:
</p>
<pre class="eval">hg commit
</pre>
<p>This commits every change reported by <code>hg status</code>.  You can limit the commit to specific files or directories using <code>hg commit <i>filenames</i></code>.  You can commit on behalf of someone else using <code>hg commit -u "Someone Else &lt;someone@example.com&gt;"</code>.  See <code>hg help commit</code> for more details.
</p>
<h4 name="Check_what_you.27re_going_to_push"> Check what you're going to push </h4>
<p>Before you push, you likely want to check what changesets will be pushed. You can do this using the <code>outgoing</code> command:
</p>
<pre class="eval">hg outgoing
</pre>
<p>This will give you a list of changesets that will be pushed to the default remote repository. Add a repository argument to see outgoing changesets for another repository.
</p>
<h4 name="Push_to_the_central_repository"> Push to the central repository </h4>
<p>To push those changes upstream to the central repository:
</p>
<pre class="eval">hg push
</pre>
<p>You'll get a bogus error message each time you push:
</p>
<pre class="eval">remote: Could not chdir to home directory : No such file or directory
</pre>
<p>Just ignore it.
</p>
<h3 name="How_do_I_deal_with_.22abort:_push_creates_new_remote_heads.21.22.3F"> How do I deal with "abort: push creates new remote heads!"? </h3>
<p>Whatever you do, don't do 'push -f' like the message suggests.  (It'll probably fail anyway, but don't try it.)
</p><p>Someone pushed new commits upstream since your last pull.  You then committed your patch locally and are trying to push that commit upstream; that upstream has a different commit that you started from.
</p><p>There are two things you can do.  The simplest is to merge your commits: run hg pull, then hg merge.  Fix up any conflicts, and then commit the merge: hg commit -m "Merge commit for bug 123456".  Then hg push as normal.  This has the unfortunate side effect of leaving an ugly minor merge commit in the revision history, and, worse, making your patch more difficult to back out if you had conflicts to fix up.
</p><p>However, it is the simplest thing to do, and is very safe.  There is another approach, but it's considerably more arcane -- a fix/replacement is in the works.
</p><p>{{template.Warning("This next approach mostly works fine, but there have been reports of patches being eaten at various times.  Take steps to back up your patch (perhaps by obtaining a diff: hg log -p -r 12345 to show the patch for rev 12345) until you\'re sure things work like you expect.")}}
</p><p>The more advanced thing you can do is to import the commit into <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension">mq</a>, pop it off the queue, update, and then commit it again before pushing:
</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>... various pull/update messages ...</i>
% <b>hg qpush</b>
applying 415.diff
Now at: 415.diff
<i>Fix up conficts as necessary; if you fixed up any, run hg qrefresh first</i>
% <b>hg qrm -r 415.diff</b>
<i>qrm -r means "remove this patch from my queue, but keep the revision"</i>
% <b>hg log -l 5</b>
<i>verify that the log looks good, with your commit on top</i>
% <b>hg push</b>
</pre>
<p>If you already use mq to manage your patches, then just make sure you pull/update right before committing and pushing your patch.  If you have problems with the above, it's ok to just do a simple merge as described previously.
</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