Mercurial repozytoriów z wieloma aktywnymi programistami?

Question

Przechodzę przez Bitbucket i nie mogę znaleźć żadnych repozytoriów Mercurial, które wyglądają tak, jak podejrzewam, że nasze repozytorium będzie wyglądało, o ile przerzucimy się na Mercurial.

Zastanawiam się, czy istnieje przepływ pracy, którego tutaj nie rozważamy?

Chodzi o to, że zrobiłem mały automatyczny test. Mamy 14 osób pracujących nad tym samym projektem, podzielonych na 4 zespoły scrumowe. Aby zasymulować 14 (wybrałem 10, okrągłą liczbę) osób pracujących równolegle na kodzie, używając Mercurial DVCS, pchając do tego samego centralnego repozytorium głównego, napisałem skrypt.

1. stworzyłem nowy "master" repozytorium, a następnie klonować go do 10 wirtualnych ludzi
2. Potem przesunął 1000 iteracji pętli, wybierając losowo klon i wykonując jedną z następujących czynności:
   • 10% czasu, czy ciągnąć od mistrza, łączenia, scalania popełnić, i naciskać
   • 90% czasu, zrobić lokalną zmianę i popełnić

Należy pamiętać, że zapewniłem, że nigdy nie doszłoby do konfliktów scalających, po prostu sprawiając, że każda wirtualna osoba będzie pracować nad własnym plikiem.

To symuluje osoby pracujące lokalnie, wykonując 1+ zatwierdzenia przed ciągnięciem, łączeniem i pchaniem (aby uniknąć 2+ głów w repozytorium głównym). Być może ten przepływ pracy jest nieprawidłowy.

Jest to próbka tego, co repozytorium teraz wygląda (zdjęcie + link do repo):

Repozytorium można znaleźć tutaj: http://hg.vkarlsen.no/hgweb.cgi/parallel_test/graph.

To wygląda okropnie niechlujnie, i jak powiedziałem, nie mogę znaleźć żadnych repozytoriów, które mają podobną historię. Mówiąc "niechlujnie", mam na myśli to, że wygląda na to, że starsza historia projektu prawie zawsze ma 10 równoległych gałęzi. Na samej górze zwęża się, ale rozszerza się, gdy ludzie, którzy aktualnie pracują w lokalnym repozytorium, popychają do mistrza.

Mam więc dwa pytania:

1. Może ktoś mi pokazać repozytorium, które ma podobną historię? Ponieważ nie mogę go znaleźć, zaczynam się zastanawiać, jakie wnioski mogę z tego wyciągnąć ...
2. Czy coś jest nie tak z naszym przepływem pracy (to znaczy z przepływem pracy, który określiłem tutaj)? Czy powinniśmy dokonać ponownej rozbudowy/squasha/transplantacji, przekazać odpowiedzialność za jedną osobę, inne rzeczy, zamiast tego, jak to się stało?

Answer 1

Imponujące przygotowanie!

1. Zawsze wygląda na brudny, jeśli wrócisz trochę i spojrzysz na wszystkie stare zatwierdzenia w tym samym czasie. Zawsze zwęża się, nawet patrząc na trochę starą historię. Zobacz na przykład http://hg.intevation.org/mercurial/crew/graph/12402?revcount=120. To nie jest najnowszy commit, ale pokazuje całą historię aż do tego zatwierdzenia.

2. Rebase pomaga całkiem sporo, zwłaszcza jeśli osoby pracują na oddzielnych obszarach. (I zazwyczaj sprawdzić przychodzące zobowiązuje się do sprawdzenia, czy istnieją potencjalne konflikty plików lub funkcjonalności, a jeśli nie, to nie zmieniają bazę.)

rebase nie jest idiotoodporny chociaż, więc scalić jest korzystnym „bezpieczne” działania, ale pozostawia więcej "śmieci" w historii. Kompromis.

Podstawa rebase jest podobna do standardowej aktualizacji SVN. Istniejące rzeczy są podstawą, a twoje zmiany idą na wierzch, przecinając palce nadal działa. Jest to przydatne, ale są chwile, kiedy czujesz się bezpieczniej, mając swoje, swoje i scalenie jako oddzielne zobowiązania w historii.

Istnieje również opcja "commit-squash" jako opcja (możliwe rozszerzenie histedit), która powoduje zgniecie wszystkich pośrednich zatwierdzeń do jednego. Jest to użyteczne, gdy masz zamiar przeforsować i chcesz przesłać wiele commitów częściowych w swoim repo jako jedno zatwierdzenie do głównej.

Answer 2

Mam 12 programistów pracujących w tym samym Mercurial repozytorium w pracy, a nasza historia wygląda zupełnie inaczej. Zdarzają się sporadyczne zatwierdzenia scalania, ale większość scaleń pochodzi z połączenia rzeczywistych oddziałów, tzn. Może nastąpić scalenie w naszej głównej gałęzi rozwojowej, wprowadzając zmiany z wydania poprawki błędu w gałęzi produkcji/wydania.

Jest to bardzo łatwe do osiągnięcia, programiści zhakują i zobowiązują się do lokalnego repozytorium i gdy mają coś stabilnego na tyle, aby dzielić się z resztą zespołu, który popychają.

Jeśli nic nie zostało popełnione od momentu, gdy rozpoczęło się, popychanie przechodzi bez problemów.

Jeśli ktoś inny dokonał zmiany, Mercurial skarży się, że push stworzy zdalne głowy. Deweloper robi następnie hg pull --rebase i ponawia próbę. Nacisk przechodzi i wszyscy są szczęśliwi.

Jeśli korzystasz z ciągłej integracji z programistami, którzy regularnie przesyłają dane do współużytkowanego repozytorium, jest to właściwa droga. Wiedza o tym, czy wprowadziłeś zmiany, czy nie, jest łatwa i unikniesz wielu bezużytecznych zobowiązań do scalania historii.