bitbucket, "hg push" i "hg update"

Question

Jeśli zacznę z lokalnym repo merkurialnym, które uważam za "główne" repozytorium (wybacz mi moich lordów) i zamierzam użyć bitbucket jako kopii zapasowej i wydać narzędzie do śledzenia, mogę wykonać wszystkie moje zmiany w moim lokalnym repozytorium i wykonać "push", aby przesłać zmiany z powrotem na bitbucket.

Nie muszę wykonywać polecenia "hg push" uruchomionego na moim komputerze lokalnym z "aktualizacją hg"?

Answer 1

Dlaczego dbasz o to, co znajduje się w katalogu roboczym na serwerach BitBucket? Tak długo jak będziesz naciskał zmiany będą w repozytorium i widoczne na stronie BitBucket.

EDYCJA: OK, zamierzam edytować tę wiadomość, aby była użyteczną odpowiedzią.

Załóżmy, że klonujesz jeden z moich repozytoriów, takich jak django-hoptoad na BitBucket. Będziesz mieć folder o nazwie django-hoptoad na lokalnym komputerze i jego zawartość będzie wyglądać mniej więcej tak:

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

wszystkie dane o repozytorium sama jest przechowywany w folderze .hg/. To tutaj Mercurial przechowuje dane o tym, które pliki zostały zmienione, w których zestawach zmian i wiele innych rzeczy.

Można myśleć o tym tak (choć jest to uproszczenie):

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

Po uruchomieniu hg pull i nie aktualizować, można wyciągnąć żadnych nowych Zestawienia zmian w repozytorium:

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 

Jeśli nie zaktualizujesz, ... my code and other folders nadal będzie równoważny z tym, co jest w changeset 2, ale inne zestawy zmian wciąż znajdują się w repozytorium.

Po uruchomieniu hg update Mercurial zaktualizuje ... my code and other folders do zawartości najnowszego zestawu zmian.

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 

Naprawdę, oznacza to, że to, co dzieje się w ... my code and other folders nie musi odpowiadać co jest w repozytorium. można po prostu usunąć go i wszystkie Zestawienia zmian nadal będzie w repozytorium:

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

Jeśli popełnione teraz, byłoby utworzyć nowy changeset że w zasadzie mówi „nie” plików. Nie musisz się jednak angażować. Ludzie wciąż mogą naciskać i wyciągać od ciebie, ponieważ repozytorium nadal ma wszystkie dane dotyczące zestawów zmian.

To prawie na pewno działa BitBucket. Nigdy nie będziesz logował się na serwerach BitBucket, edytowałeś swojego kodu i zatwierdzałeś go - będziesz tylko naciskać/ciągnąć/klonować. Oznacza to, że ... my code and other folders nigdy nie zostanie użyty, więc wyobrażam sobie, że Jesper skonfigurował go do usunięcia, aby zaoszczędzić miejsce na dysku.

Od hg update tylko naprawdę wpływa na katalog roboczy, a katalog roboczy na BitBucket nigdy nie jest używany, nie trzeba uruchamiać hg update po naciśnięciu przycisku BitBucket.

Answer 2

Nie trzeba wykonywać aktualizacji hg na lokalnym komputerze. Aktualizacja jest używana, gdy dane są przekazywane do lokalnego repozytorium, a użytkownik przesyła dane z lokalnego repozytorium.

Answer 3

Myślę, że możesz się mylić między working copy (aka katalog roboczy) i lokalnym repository. Są to powiązane, ale oddzielne rzeczy. Lokalne repozytorium zawiera pełną historię wszystkich śledzonych plików natomiast kopia robocza zawiera wersje plików z określonego rewizji plus Twój zmian do nich

Komenda hgpush i pull zmiany przechodzić między repozytoriami i update i commit przesunie zmian między kopią roboczą a lokalnym repozytorium. Jeśli

Więc push zmiany zdalnego repozytorium że nie zmieni lokalnego repozytorium, a więc nie ma potrzeby, aby uruchomić update na lokalnej repozytorium. Jednak każda osoba korzystająca z repozytorium musi mieć numer update, aby zmiany zostały wprowadzone w kopii roboczej. I odwrotnie, jeśli zmienisz ze zdalnego repozytorium pull, będziesz musiał wykonać update, aby zmiany te były widoczne w kopii roboczej.

Podobnie, wszystkie zmiany z kopii roboczej do commit należy wprowadzić do lokalnego repozytorium, zanim zostaną one wysłane do innego repozytorium za pomocą push.

Answer 4

Bitbucket pokazuje repozytorium . Jak zauważył Dave Webb, hg update zajmuje się aktualizacją kopii roboczej . Kiedy wykonujesz hg push, przesyłasz zestawy zmian w celu aktualizacji repozytorium na Bitbucket - tak więc interfejs WWW to pokaże.

Nie ma kopii roboczych na Bitbucket, jak wskazał Steve Losh. Nie ma również potrzeby wykonania za plecami.

Można eksperymentować z tym sam, dokonując klon bez kopii roboczej:

% hg clone --noupdate repo repo-empty 

następnie przejść do repo-empty i zrobić hg log. Zobaczysz, że pomimo tego, że nie ma tam plików, archiwum historii (tj. repozytorium) zostało jeszcze sklonowane.Można udostępnić pliki pojawiają się polecenia do hg update:

% hg update 

i zniknie z

% hg update null 

kopii roboczej jest potrzebne tylko jeśli chcesz spojrzeć na pliki i tworzyć nowe rewizje. W przeciwnym razie możesz go usunąć, aby zaoszczędzić miejsce. Zwykle robi się to w klonach, które są używane tylko do serwowania z hg serve lub równoważną rzeczą, której używa Bitbucket.