bitbucket, "hg push" y "hg update"

Question

Si empiezo con un repositorio local mercurial, que considero que es el repositorio "principal" (perdón por mis señores de DVD), y tengo la intención de utilizar bitbucket como respaldo y facilidad de seguimiento de problemas, puedo hacer todos mis cambios en mi repositorio local y hacer un "hg push" para devolver los cambios a bitbucket.

¿No necesito seguir este comando "hg push" en mi máquina local con una "actualización de hg"?

Answer 1

¿Por qué le importa lo que está en el directorio de trabajo en los servidores de BitBucket? Mientras empuje los cambios estarán en el repositorio y serán visibles en la página de BitBucket.

EDITAR: Bien, voy a editar esto para que sea una respuesta útil.

Digamos que clonan uno de mis repositorios como django-hoptoad en BitBucket. Vas a tener una carpeta llamada django-hoptoad en su máquina local y su contenido se verá algo como esto:

django-hoptoad/ 
| 
+-- .hg/ 
| 
+-- ... my code and other folders 

Todos los datos sobre el propio repositorio se almacena en la carpeta .hg/. Ahí es donde Mercurial guarda los datos sobre qué archivos se cambiaron en qué conjuntos de cambios y muchas otras cosas.

Se puede pensar en ello como esto (aunque es una simplificación excesiva):

django-hoptoad/ 
| 
+-- .hg/ 
| | 
| +-- data about changeset 1 
| +-- data about changeset 2 
| 
+-- ... my code and other folders as they appear in changeset 2 

Cuando se ejecuta hg pull y no actualiza, se tira cualquier nuevo conjuntos de cambios en el repositorio:

django-hoptoad/ 
| 
+-- .hg/ 
| | 
| +-- data about changeset 1 
| +-- data about changeset 2 
| +-- data about changeset 3 (NEW) 
| +-- data about changeset 4 (NEW) 
| 
+-- ... my code and other folders as they appear in changeset 2 

Si no actualiza, ... my code and other folders seguirá siendo equivalente a lo que está en changeset 2, pero los otros conjuntos de cambios todavía están en el repositorio.

Cuando ejecuta hg update Mercurial actualizará el ... my code and other folders al contenido del último conjunto de cambios.

django-hoptoad/ 
| 
+-- .hg/ 
| | 
| +-- data about changeset 1 
| +-- data about changeset 2 
| +-- data about changeset 3 
| +-- data about changeset 4 
| 
+-- ... my code and other folders as they appear in changeset 4 

En realidad, esto significa que lo que pasa a estar en ... my code and other folders no tiene que coincidir con lo que hay en el repositorio. Se podía eliminarlo y todos los conjuntos de cambios todavía estaría en el repositorio:

django-hoptoad/ 
| 
+-- .hg/ 
     | 
     +-- data about changeset 1 
     +-- data about changeset 2 
     +-- data about changeset 3 
     +-- data about changeset 4 

Si cometió en este momento, sería crear un nuevo conjunto de cambios que básicamente dice "no hay archivos". Sin embargo, no tienes que comprometerte. Las personas aún pueden empujar y tirar porque el repositorio aún tiene todos los datos sobre los conjuntos de cambios.

Esto es casi seguro lo que BitBucket está haciendo. Nunca vas a iniciar sesión en los servidores de BitBucket, editaremos tu código y nos comprometeremos allí; solo vas a empujar/tirar/clonar. Eso significa que el ... my code and other folders nunca se utilizará realmente, así que me imagino que Jesper lo tiene configurado para eliminarlo y ahorrar espacio en el disco.

Dado que hg update solo afecta realmente al directorio de trabajo, y el directorio de trabajo en BitBucket nunca se usa, no necesita ejecutar hg update después de presionar BitBucket.

Answer 2

No es necesario hacer una actualización de hg en su máquina local. La actualización se usa cuando los datos se envían a su repositorio local, y usted está presionando desde su repositorio local.

Answer 3

Creo que se puede confundir entre el working copy (también conocido como directorio de trabajo) y el repository local. Estas son cosas relacionadas pero separadas. El repositorio local contiene el historial completo de todos los archivos rastreados mientras que la copia de trabajo contiene versiones de los archivos de una revisión en particular, además de los cambios en ellos,

El comando hgpush y pull cambios moverse entre repositorios y update y commit mueve cambios entre su copia de trabajo y su repositorio local.

Así que si push cambios en el repositorio remoto que no va a cambiar el repositorio local y lo que no hay necesidad de ejecutar un update en el repositorio local. Sin embargo, cualquiera que use el repositorio remoto necesitará hacer un update para que sus cambios se muestren en su copia de trabajo. Por el contrario, si cambia pull desde un repositorio remoto, necesitará hacer un update para que estos cambios se muestren en su copia de trabajo.

Del mismo modo, necesita commit todos los cambios de su copia de trabajo en el repositorio local antes de que puedan enviarse a otro repositorio usando push.

Answer 4

Bitbucket le muestra el repositorio . Como señaló Dave Webb, hg update tiene que ver con la actualización de la copia de trabajo . Cuando lo haces hg push estás transfiriendo conjuntos de cambios para actualizar el repositorio en Bitbucket, y así la interfaz web lo mostrará.

No hay copias de trabajo en Bitbucket, como lo señala Steve Losh. Tampoco se está haciendo hg update detrás de su espalda.

Usted puede experimentar con esto por sí mismo al hacer un clon sin una copia de trabajo:

% hg clone --noupdate repo repo-empty 

Entonces entra en repo-empty y hacer hg log. Verá que, aunque no haya archivos allí, el historial (es decir, el repositorio ) aún se ha clonado.Puede hacer que los archivos aparecen con el comando hg update:

% hg update 

y desaparecer de nuevo con

% hg update null 

La copia de trabajo sólo es necesario si desea buscar en los archivos y hacer nuevas confirmaciones. De lo contrario, puede eliminarlo para ahorrar espacio. Esto normalmente se hace en clones que solo se utilizan para servir con hg serve o lo que Bitbucket utiliza.