Jaki jest dobry wzór użycia Mercurial dla tej konfiguracji?

Question

Mamy dwóch deweloperów w tej samej zamkniętej (głupiej, głupiej gov) sieci, Kolejny deweloper kilka minut jazdy w dół drogi i czwarty deweloper w połowie drogi w całym kraju. E-mail, ftp i media do usuwania to wszystkie możliwe metody przesyłania dla osób spoza tej samej sieci.

Jestem jednym z dwóch twórców zamkniętej sieci, uważamy nas za lokalizację "główną".

Jaka jest najlepsza konfiguracja/wzór Mercurial dla grupy? Jaki jest najlepszy sposób przesyłania zmian do/od zdalnych programistów? Ponieważ jestem odpowiedzialny za to, doszedłem do wniosku, że będę musiał zachować przynajmniej jedno master repo z innym lokalnym repo, w którym będę mógł się rozwijać. Każda inna osoba powinna po prostu potrzebować klona mistrza. Czy to jest poprawne? Myślę, że to również sprawia, że ​​jestem odpowiedzialny za scalanie?

Jak widać, wciąż próbuję objąć kontrolę nad wersją rozproszoną. Nie sądzę, że jest jakikolwiek inny sposób na zrobienie tego z sytuacją łączności.

Answer 1

Użytkownicy spoza sieci mogą dokonać patches i/lub użyć email, aby wysłać aktualizacje głównego repo lub kogoś takiego jak ty, aby je scalić. Inni wewnętrzni ludzie mogą mieć lokalne kopie, takie jak Ty i łączą się - ale jeśli masz je poza łatami sieciowymi, lepiej, żeby jedna osoba radziła sobie z nimi, aby nikt się nie pomylił, ale to jest coś, co musiałbyś rozważ siebie.

Synchronizując w drugą stronę, utworzysz łatkę, a oni wyślą wiadomość e-mail lub dostaną dysk flash do zdalnych programistów, aby załatali swój system. Będziesz potrzebował dobrej komunikacji w zespole, jestem wdzięczny, że nie jestem w twoich butach.

To są moje jedyne sugestie - dobrze, oczywiste, daj im połączenie VPN! Chciałbym usłyszeć, jak to idzie, jakie plany stabilizują się w cotygodniowy groove.

Answer 2

Prawidłowo. Jedyny sposób, w jaki wszystko trafia do zamkniętej sieci, to pamięć flash.

Answer 3

Łaty są prostym i wszechstronnym rozwiązaniem.

W celu poruszania się po większych grupach zmian (szczególnie zmian binarnych i fuzji), Mercurial oferuje pakiety binarne. Pakiet to w zasadzie binarny materiał, który jest wysyłany w sieci, gdy robisz hg push, ale tutaj jest przechwytywany w pliku.

Wyobraźmy sobie, że jakoś zdobyłem klona (przez pendrive, DVD itp.). Nazywają to upstream. Następnie robię drugi klon, nazywam go devel. Cały mój rozwój robię w devel i robię wiele commitów, scaleń itp. Ponieważ Mercurial jest rozprowadzany, mogę to wszystko robić offline.

Aby zobaczyć, które Zestawienia zmian brakuje w upstream zrobić

% hg outgoing ../upstream 

Kiedy mam coś wysłać, mogę używać

% hg bundle changes.hg ../upstream 

dostać binarny plik skompresowany, które zawierają Zestawienia zmian w tym wszystkim ich meta dane. Mogę wtedy nagrać ten plik na CD i wysłać pocztą ...

Odbiorca pakietu może zrobić

% hg incoming changes.hg 

aby zobaczyć listę changeset i

% hg pull changes.hg 

rozpakować i dodać Zestawienia zmian do swojego repozytorium. Najprawdopodobniej będzie musiał się połączyć - dokładnie tak, jakby ściągnął bezpośrednio ze swojego repozytorium przez HTTP lub SSH.

Uwaga, repozytorium upstream służy tylko do wygodnego zapamiętania, które zestawy zmian zostały już znalezione w repozytorium. Możesz także zanotować identyfikator zestawu zmian i użyć hg bundle --base podczas pakowania, aby określić podstawowy (zwykły) zestaw zmian. Zobacz hg help bundle lub look in the wiki.