bitbucket, "hg push" und "hg update"

Question

Wenn ich mit einem lokalen mercurial Repo, die ich für die "Haupt" -Repo (entschuldigen Sie mich meine DVCs Lords), beginnen und beabsichtigen, bitbucket als Backup zu verwenden Ich kann alle meine Änderungen in meinem lokalen Repo machen und einen "hg push" machen, um die Änderungen zurück an bitbucket zu senden.

Muss ich nicht diesem Befehl "hg push" folgen, der auf meinem lokalen Rechner mit einem "hg update" ausgeführt wird?

Answer 1

Warum interessiert es dich, was im Arbeitsverzeichnis auf BitBuckets Servern ist? Solange Sie pushen, sind die Änderungen im Repository und auf der BitBucket-Seite sichtbar.

EDIT: OK, ich werde dies bearbeiten, um eine sinnvolle Antwort zu sein.

Angenommen, Sie klonen eines meiner Repositories wie django-hoptoad auf BitBucket. Sie werden einen Ordner django-hoptoad auf dem lokalen Computer benannt haben und deren Inhalt so etwas wie folgt aussehen:

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

Alle Daten über das Repository selbst im .hg/ Ordner gespeichert ist. Dort speichert Mercurial die Daten darüber, welche Dateien in welchen Changesets geändert wurden, und viele andere Dinge.

Sie können so denken es (obwohl es eine grobe Vereinfachung):

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

Wenn Sie hg pull laufen und nicht aktualisieren, ziehen Sie neue Changesets in das 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 

Wenn Sie nicht aktualisieren, entspricht das ... my code and other folders immer noch dem, was in changeset 2 ist, aber die anderen Änderungssets befinden sich immer noch im Repository.

Wenn Sie ausführen, wird Mercurial die ... my code and other folders auf den Inhalt des neuesten Changeset aktualisieren.

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 

Wirklich, das bedeutet, dass das, was in ... my code and other folders passiert sein muss nicht übereinstimmen, was im Repository ist. Sie könnten einfach löschen und alle Changesets noch im Repository würde:

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

Wenn Sie jetzt verpflichtet, wäre es eine neue changeset zu erstellen, die „keine Dateien“ im Grunde sagt. Sie müssen sich jedoch nicht festlegen. Die Leute können immer noch pushen und ziehen, weil das Repository immer noch alle Daten über die Changesets enthält.

Dies ist fast sicher, was BitBucket tut. Sie werden sich nie bei den Servern von BitBucket anmelden, Ihren Code bearbeiten und dort committen - Sie werden nur Push/Pull/Klonen machen. Das bedeutet, dass die ... my code and other folders nie wirklich verwendet wird, also würde ich mir vorstellen, Jesper hat es eingerichtet, um es zu löschen, um den Speicherplatz zu sparen.

Da nur das Arbeitsverzeichnis betrifft und das Arbeitsverzeichnis auf BitBucket nie verwendet wird, müssen Sie nicht ausführen, nachdem Sie zu BitBucket drücken.

Answer 2

Keine Notwendigkeit, ein hg Update auf Ihrem lokalen Rechner zu tun. Update wird verwendet, wenn Daten an Ihr lokales Repository gesendet werden und Sie von Ihrem lokalen Repository aus pushen.

Answer 3

Ich denke, Sie könnten zwischen dem working copy (aka Arbeitsverzeichnis) und dem lokalen repository verwirrt werden. Dies sind verwandte, aber getrennte Dinge. Das lokale Repository enthält die vollständige Historie aller verfolgt Dateien, während die Arbeitskopie enthält Versionen der Dateien aus einer bestimmten Revision sowie die Änderungen zu ihnen

Der hg Befehl push und pull bewegen Änderungen zwischen Repositories und update und commit bewegt Änderungen zwischen Ihrer Arbeitskopie und Ihrem lokalen Repository.

Also, wenn Sie push Änderungen an eine Remote-Repository zur Verfügung, und so wird nicht das lokale Repository ändern gibt es keine Notwendigkeit, ein update auf die lokalen Repository zu laufen. Jeder, der das entfernte Repository verwendet, muss jedoch eine update durchführen, damit Ihre Änderungen in der Arbeitskopie angezeigt werden. Umgekehrt, wenn Sie pull Änderungen von einem Remote-Repository müssen Sie eine update tun, damit diese Änderungen in Ihrer Arbeitskopie angezeigt werden.

In ähnlicher Weise müssen Sie alle Änderungen von Ihrer Arbeitskopie in das lokale Repository übertragen, bevor sie mit push an ein anderes Repository gesendet werden können.

Answer 4

Bitbucket zeigt Ihnen die Repository. Wie von Dave Webb ausgeführt, betrifft hg update die Aktualisierung der Arbeitskopie. Wenn Sie hg push machen, übertragen Sie Changesets, um das Repository auf Bitbucket zu aktualisieren - und das Webinterface zeigt dies an.

Es gibt keine Arbeitskopien auf Bitbucket, wie Steve Losh darauf hingewiesen hat. Es gibt auch keine hinter Ihrem Rücken getan.

Sie können ohne eine Arbeitskopie, indem sie einen Klon mit diesem selbst experimentieren:

% hg clone --noupdate repo repo-empty 

dann in repo-empty gehen und hg log tun. Sie werden sehen, dass, obwohl es dort keine Dateien gibt, die Geschichte (d. H. Das Repository) immer noch geklont wurde.Sie können die Dateien mit dem Befehl hg update erscheinen:

% hg update 

und verschwinden wieder mit

% hg update null 

Die Arbeitskopie wird nur benötigt, wenn man sich den Dateien suchen möchten und neue Commits zu machen. Andernfalls können Sie es entfernen, um Platz zu sparen. Dies wird normalerweise in Clones gemacht, die nur zum Servieren mit hg serve oder dem Äquivalent, das Bitbucket verwendet, verwendet werden.