Mercurial: vuelva a la versión anterior y continúe desde allí


249

Estoy usando Mercurial localmente para un proyecto (es el único repositorio que no hay empujar / tirar hacia / desde cualquier otro lugar).

Hasta la fecha tiene una historia lineal. Sin embargo, en lo que estoy trabajando ahora me he dado cuenta de que es un enfoque terrible y quiero volver a la versión antes de comenzar e implementarla de una manera diferente.

Estoy un poco confundido con los comandos branch/ revert/ update -Cen Mercurial. Básicamente quiero volver a la versión 38 (actualmente en 45) y tener mis próximos commits tener 38 como padre y continuar desde allí. No me importa si las revisiones 39-45 se pierden para siempre o terminan en una rama sin salida propia.

¿Qué comando / conjunto de comandos necesito?


66
Para todos los interesados, esto ha aparecido en la barra lateral relacionada, que es una gran explicación de reversión vs actualización: stackoverflow.com/questions/2506803/…
Paolo

Respuestas:


150
hg update [-r REV]

Si luego se compromete, creará efectivamente una nueva rama. Luego, puede continuar trabajando solo en esta rama o, finalmente, fusionar la existente en ella.


66
El próximo commit creará una nueva rama. Si no está seguro, solo haga una copia de seguridad de su repositorio (con copia de trabajo), pruébelo - no me gusta el resultado -> comience desde cero sin costo alguno
van

Esta es una respuesta dudosa, ya que combina sus cambios actuales con la revisión anterior, que es probablemente lo que no desea hacer. La respuesta correcta debería ser hg revert.
Trevor de Koekkoek

La respuesta está bien, excepto un poco sobre la fusión (no creo que el interlocutor quiera fusionar).
ctrl-alt-delor

3
@NeonWarge REV es simplemente un marcador de posición para la revisión. Puede ser su número, su hash, un marcador, etc. Trevor: esto no es dudoso porque no combina nada. No hay necesidad de.
DanMan

401

Aquí está la hoja de trucos sobre los comandos:

  • hg updatecambia la copia principal de la copia de trabajo y también cambia el contenido del archivo para que coincida con esta nueva revisión principal. Esto significa que las nuevas confirmaciones continuarán desde la revisión a la que actualice.

  • hg revertsolo cambia el contenido del archivo y deja sola la copia principal de la copia de trabajo. Normalmente lo utiliza hg revertcuando decide que no desea conservar los cambios no confirmados que ha realizado en un archivo en su copia de trabajo.

  • hg branchcomienza una nueva rama con nombre. Piense en una rama con nombre como una etiqueta que asigna a los conjuntos de cambios. Entonces, si lo hace hg branch red, los siguientes conjuntos de cambios se marcarán como pertenecientes a la rama "roja". Esta puede ser una buena manera de organizar conjuntos de cambios, especialmente cuando diferentes personas trabajan en diferentes ramas y luego desea ver de dónde se originó un conjunto de cambios. Pero no quieres usarlo en tu situación.

Si lo usa hg update --rev 38, los conjuntos de cambios 39–45 se dejarán como un callejón sin salida, una cabeza colgante como la llamamos. Recibirás una advertencia cuando presiones, ya que estarás creando "cabezas múltiples" en el repositorio al que presionas. La advertencia está ahí, ya que es un poco descortés dejar esas cabezas ya que sugieren que alguien necesita fusionarse. Pero en su caso, puede seguir adelante y hg push --forceya que realmente desea dejarlo colgado.

Si aún no ha enviado la revisión 39-45 a otro lugar, puede mantenerlos privados. Es muy simple: con hg clone --rev 38 foo foo-38usted obtendrá un nuevo clon local que solo contiene hasta la revisión 38. Puede continuar trabajando foo-38e impulsar los nuevos (buenos) conjuntos de cambios que cree. Todavía tendrá las revisiones antiguas (malas) en su fooclon. (Usted es libre de cambiar el nombre de los clones que le apetezca, por ejemplo, fooa foo-bady foo-38a foo.)

Finalmente, también puede usar hg revert --all --rev 38y luego confirmar. Esto creará una revisión 46 que se ve idéntica a la revisión 38. Luego continuará trabajando desde la revisión 46. Esto no creará una bifurcación en el historial de la misma manera explícita que lo hg updatehizo, pero por otro lado no recibirá quejas por tener Múltiples cabezas. Lo usaría hg revertsi estuviera colaborando con otros que ya han hecho su propio trabajo basado en la revisión 45. De lo contrario, hg updatees más explícito.


2
IMPRESIONANTE respuesta. Usé hg revert --all --rev ## y me salvó el trasero: D
Van Thoai Nguyen

1
¿No sería mejor cerrar también la rama de la cabeza colgante? Esto evitaría futuras advertencias en el repositorio. Ver stackoverflow.com/a/3688320/900130
Zoltán

nota: hg revert --all --rev xxx modificará los archivos locales necesarios para revertir desde donde se encuentra en su repositorio local. Por lo tanto, debe actualizar antes de dónde desea volver.
Vincent

Para ramificar una versión anterior, primero tuve que hacer una reversión y luego una actualización. Dicho esto, una explicación menos opaca que la mayoría.
CodeLurker

30

Acabo de encontrar un caso de necesidad de revertir solo un archivo a la revisión anterior, justo después de haber hecho commit y push. La sintaxis abreviada para especificar estas revisiones no está cubierta por las otras respuestas, así que aquí hay un comando para hacerlo

hg revert path/to/file -r-2

Eso -2revertirá a la versión anterior a la última confirmación, el uso -1solo revertiría los cambios actuales no confirmados.


1
Encuentro esto extremadamente útil. Por supuesto, para la opción -r, simplemente puede proporcionar el número de revisión
Alex

También puede seleccionar una revisión específica. Por ejemplohg revert path/to/file -r478
Matt

7

En mi humilde opinión, se hg strip -r 39adapta mejor a este caso.

Requiere que la extensión mq esté habilitada y tiene las mismas limitaciones que el "método de repositorio de clonación" recomendado por Martin Geisler: si el conjunto de cambios se publicó de alguna manera, (probablemente) volverá a su repositorio en algún momento porque solo cambió su repositorio local


No sabía sobre este. Más fácil y limpio que eliminar y volver a clonar el repositorio. Gracias.
Restablece a Monica - notmaynard el

6

Después de usarlo, hg update -r REVno estaba claro en la respuesta sobre cómo confirmar ese cambio para que luego pueda presionar.

Si solo intenta confirmar después de la actualización, Mercurial no cree que haya ningún cambio.

Primero tuve que hacer un cambio en cualquier archivo (digamos en un archivo LÉAME) para que Mercurial reconociera que había hecho un nuevo cambio, luego podría confirmarlo.

Esto creó dos cabezas como se mencionó.

Para deshacerme de la otra cabeza antes de empujar, seguí el paso No-Op Merges para remediar esa situación.

Entonces pude empujar.


puedes hacer una commit --close-branchen la rama vieja. También puede push -fempujar nuevas cabezas, pero esto puede causar confusión en cuanto a cuál es la actual.
ctrl-alt-delor

5

Las respuestas anteriores fueron muy útiles y aprendí mucho. Sin embargo, para mis necesidades, la respuesta sucinta es:

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

donde ${1}es el número de la revisión o el nombre de la sucursal. Estas dos líneas son en realidad parte de un script bash, pero funcionan bien por sí solas si desea hacerlo manualmente.

Esto es útil si necesita agregar una revisión a una rama de lanzamiento, pero necesita construir desde el valor predeterminado (hasta que obtengamos nuestras herramientas de CI correctas y capaces de construir desde ramas y luego eliminar las ramas de lanzamiento también).


1

Instalaría Tortoise Hg (una GUI gratuita para Mercurial) y la usaría. A continuación, puede hacer clic con el botón derecho en una revisión a la que desee regresar, con todos los mensajes de confirmación allí delante de sus ojos, y 'Revertir todos los archivos'. Lo hace intuitivo y fácil de retroceder y avanzar entre versiones de un conjunto de archivos, lo que puede ser realmente útil si está buscando establecer cuándo apareció un problema por primera vez.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.