bitbucket, “hg push” e “hg update”

Question

Se inizio con un pronti contro termine mercuriale locale, che io ritengo essere la "principale" pronti contro termine (me i miei DVCS signori perdono), e intende utilizzare bitbucket come una struttura di backup e gestione dei problemi, non posso fare tutte le mie modifiche nel mio repo locale e fare un "hg push" per inviare le modifiche al bitbucket.

Non ho bisogno di seguire questa "hg push" comando Esegui sulla mia macchina locale con una "hg update"?

Answer 1

Perché ti interessa cosa c'è nella directory di lavoro sui server di bitbucket? Finché si spingono i cambiamenti saranno nel repository e visibile sulla pagina BitBucket.

EDIT:. OK, ho intenzione di modificare questo per essere una soluzione utile

Di 'si clona giù uno dei miei repository come django-hoptoad su BitBucket. Avrete una cartella denominata django-hoptoad sul computer locale e il suo contenuto sarà simile a questo:

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

Tutti i dati circa il repository stesso viene memorizzato nella cartella .hg/. Ecco dove Mercurial mantiene i dati su quali file sono stati modificati in quali gruppi di modifiche, e un sacco di altre cose.

Si può pensare a come questo (anche se è una semplificazione eccessiva):

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

Quando si esegue hg pull e non si aggiorna, si tira tutti i nuovi gruppi di modifiche al repository:

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

Se non si aggiorna, il ... my code and other folders sarà ancora equivalente a tutto ciò che è in changeset 2, ma gli altri gruppi di modifiche sono ancora nel repository.

Quando si esegue hg update Mercurial aggiornerà il ... my code and other folders per il contenuto del più recente di modifiche.

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

In realtà, questo significa che ciò che accade di essere in ... my code and other folders non deve corrispondere a ciò che è nel repository. Si potrebbe semplicemente eliminarlo e tutti i gruppi di modifiche sarebbe ancora nel repository:

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

Se hai commesso in questo momento, si creerebbe un nuovo changeset che in pratica dice "no file". Non è necessario impegnarsi però. La gente può ancora spingere e tirare da voi, perché il repository ha ancora tutti i dati relativi ai gruppi di modifiche.

Questa è quasi certamente quello BitBucket sta facendo. Si è mai andare per accedere al server di bitbucket, modificare il codice e si impegnano lì - si sta sempre e solo andando a spingere / tirare / clone. Ciò significa che non sarà mai effettivamente utilizzato il ... my code and other folders, quindi mi piacerebbe immaginare Jesper ha impostato per eliminarlo per risparmiare spazio su disco.

Dal hg update colpisce veramente solo la directory di lavoro, e la directory di lavoro sulla BitBucket non viene mai utilizzato, non è necessario eseguire hg update dopo aver premuto a BitBucket.

Answer 2

Credo che si potrebbe ottenere confuso tra la di lavoro copia (directory di lavoro aka ) e il repository. Questi sono legati, ma le cose separate. Il repository locale contiene la storia completa di tutti i file monitorati mentre la copia di lavoro contiene le versioni dei file da una particolare revisione, più le modifiche apportate a loro,

Il comando hg push e pull spostare modifiche tra repository e update e commit muove modifiche tra copia di lavoro e il vostro repository locale.

Quindi, se si push modifiche a un repository remoto che non cambierà il repository locale e quindi non c'è bisogno di eseguire un update sul locale repository. Tuttavia, chiunque utilizzi il remoto repository sarà necessario fare un update in modo che le modifiche sono mostrati nella loro copia di lavoro. Al contrario, se si pull cambiamenti da un repository remoto è necessario fare un update in modo che questi cambiamenti sono mostrati nella copia di lavoro.

Allo stesso modo, è necessario commit tutte le modifiche dalla copia di lavoro nel repository locale, prima che possano essere inviati a un altro repository utilizzando push.

Answer 3

Bitbucket vi propone i repository . Come sottolineato da Dave Webb, hg update riguarda l'aggiornamento del copia di lavoro . Quando si esegue hg push si sta trasferendo gruppi di modifiche al fine di aggiornare il repository su Bitbucket -. E così l'interfaccia web mostrerà questo

Non ci sono copie di lavoro su Bitbucket, come sottolineato da Steve Losh. Non c'è inoltre hg update stato fatto dietro la schiena.

Si può sperimentare con questo voi stessi facendo un clone senza una copia di lavoro:

% hg clone --noupdate repo repo-empty

poi andare in repo-empty e fare hg log. Vedrete che anche se non ci sono file di lì, il storia (vale a dire, il repository ) è ancora stato clonato. È possibile rendere i file vengono visualizzati con il comando hg update:

% hg update

e sparire di nuovo con

% hg update null

La copia di lavoro è necessaria solo se si desidera guardare i file e fare nuove commit. In caso contrario, è possibile rimuoverlo per risparmiare spazio. Questo avviene normalmente nei cloni che vengono utilizzati solo per servire con hg serve o la cosa equivalente che utilizza Bitbucket.

Answer 4

Non c'è bisogno di fare un aggiornamento hg sul computer locale. Aggiornamento viene utilizzato quando i dati viene spinto al repository locale, e si stanno spingendo dal repository locale.