¿Cómo mantener los cambios no confirmados en un repositorio mercurial local, mientras se sigue empujando/tirando? Usando hgeclipse

Question

El mayor problema que estoy teniendo es que si estoy trabajando en algunos archivos que no quiero comprometer, solo los guardo .. Luego tengo otros archivos que quiero enviar al servidor, sin embargo, si alguien más ha hecho cambios en el repositorio, y yo los jalé hacia abajo. Me pide fusionar o volver a establecer la base. Cualquiera de estas opciones me hará perder mis cambios locales que no he cometido.

¿Qué están haciendo otras personas para evitar esto? Encuentro que la documentación de la extensión de estantería es difícil de manejar.

Estoy usando Mercurial Eclipse para empujar y extraer archivos hacia y desde el servidor. ¡Cualquier explicación de esto sería muy apreciada! ¡Gracias!

Ejemplo:

estoy trabajando en mi sitio web en Mercurial Eclipse .. Tengo una nueva carpeta y los nuevos archivos que no quieren comprometerse con el servidor por el momento. También modifiqué algunos archivos existentes y aún no deseo hacer esos cambios en vivo. Luego algo en mi sitio web se rompe y tengo que arreglarlo, no me deja arreglarlo sin volver a basarme o fusionarme con el último consejo del repositorio y esto me hará perder todos mis cambios no confirmados. ¿Qué debo hacer con mi nueva carpeta y archivos que he editado si no quiero perderla? Volver a clonar parece tedioso. Copiar los archivos a una nueva carpeta también parece tedioso. Estoy seguro de que Shelving o MQ harán lo que yo quiero, simplemente aún no sé cómo hacerlo.

Answer 1

Estoy seguro de que alguien lo ayudará a encontrar una solución incorrecta, pero la mejor opción es cambiar sus objetivos, simplemente comprométalo. El código que no se ha confirmado no se ha escrito. Si positivamente no puede soportar tener commits frecuentes en su historial, use Mercurial Queues con un repositorio de colas y comprométalo. A continuación, puede abrir los conjuntos de cambios, presionar/arrastrar/fusionar y volver a presionarlos, y todo el trabajo valioso se confirmará en la cola de parches.

Answer 2

Con referencia a su situación de ejemplo, esto es lo que haría (siguiendo la estrategia de Ry4an simplemente cometer las cosas que se está trabajando, pero no quiero publicar ya):

Se supone que comience a trabajar en un repositorio como este:

$ hg status -A 
C f1 
C f2 
$ hg glog 
@ changeset: 1:7f3c6c86a92f 
| tag:   tip 
| summary:  add f2 
| 
o changeset: 0:03ca1e6d5b86 
    summary:  initial 

Eso es que hay 2 archivos y 2 commits/changesets. Usted hace un trabajo, digamos que añadir una nueva característica, y luego su copia de trabajo podría tener este aspecto:

$ hg status 
M f2 
? f3 
? f4 

hay 2 y 1 archivo modificado. Ahora tiene que corregir un error para el que también necesita nuevos cambios en un repositorio remoto. Instantánea su trabajo actual, comprometiéndose él y tirar de los cambios remotos (en qué orden usted eso no importa, un tirón de forma predeterminada no toca el estado de su copia de trabajo):

$ hg commit -A -m "snapshot feature work" 
$ hg pull 

Esto puede dar lugar a una la historia de esta manera:

o changeset: 3:2284ba62de07   <-- just pulled in 
| tag:   tip 
| parent:  1:7f3c6c86a92f 
| summary:  edit f1 
| 
| @ changeset: 2:4a19d371a04f   <-- your interrupted work 
|/ summary:  snapshot feature work 
| 
o changeset: 1:7f3c6c86a92f 
| summary:  add f2 
| 
o changeset: 0:03ca1e6d5b86 
    summary:  initial 

Ahora se puede actualizar a la revisión 3/caja y empezar a corregir errores:

$ hg update 3 
.. fix the bug .. 
$ hg commit -m "fix a bug" 
$ hg glog --limit 3 
@ changeset: 4:5d3d947fb4af 
| tag:   tip 
| summary:  fix a bug 
| 
o changeset: 3:2284ba62de07 
| parent:  1:7f3c6c86a92f 
| summary:  edit f1 
| 
| o changeset: 2:4a19d371a04f 
|/ summary:  snapshot feature work 
: 

se ve bien, vamos a empujar a su solución, es decir,lo convierten en vivo, mientras no publicar su trabajo intermedia:

$ hg push -r 4 

Esto empuja a todos los cambios que llevan a la revisión 4, su corrección de errores, pero no hay otras sucursales en su repositorio local. También puede usar -r ., que hace referencia a la revisión principal de su copia de trabajo, es decir, la revisión que acaba de realizar.

Por último, puede volver a su trabajo función y continuar su trabajo:

$ hg update 2 
.. work, commit, work, commit .. 
.. finally merge with the other branch, e.g. revision 4 

Estos pasos están en la línea de comandos, pero creo que no es de difícil de adaptar el concepto general de correspondientes clics en el Complemento Eclipse Mercurial.

Algunas notas adicionales:

• Es posible que desee marcador la instantánea cometió, por lo que no necesita trabajar con identificador de la revisión o números.
• Si desea publicar su trabajo de funciones en una confirmación única más tarde, utilice la extensión de colapsar una vez que haya terminado.