millennium-dev team mailing list archive

[Rafał Cieślak <rafalcieslak256@xxxxxxxxxx>]

Ze względu na to, że mam ogólnie wyjątkowo niski odzew od kogokolwiek już
od piątku, a wtedy nikt nie protestował przed terminem niedzieli, to
pozwolę sobie poczekać z wywaleniem treningu do północy, a potem śmiało
kasuję i wrzucam coś prawdziwego.


Na temat pisania kodu w osobnych gałązkach:
Z osobnymi gałązkami to jest tak, że intencją jest trzymać zmiany w osobnym
miejscu, na takie tymczasowe przetrzymanie, by można było je oglądać,
oceniać, komentować *zanim* trafią do trunka.
W tym sens MP jest taki, że jak sama nazwa wskazuje, jest to
*propozycja* wepchnięcia
zmian wprowadzonych w jakiejś gałązce do trunka.

Z grubsza rzecz biorąc, to pracując w osobnej gałązce *nigdy* nie będziesz
jej pushował do trunka. Osobne gałązki wrasta się w pień, (tj w pniu
wykonuje się bzr merge [inna gałązka]).

Zatem taki ogólny schemat pracy przy robieniu czegoś w osobnej gałązce
wygląda mniej więcej tak:

1. Rozgałęziamy się (ściągamy sobie na dysk kopię pnia za pomocą bzr branch)
2. Wprowadzamy zmiany
3. Commitujemy zmiany
     Kroki 2 i 3 powtarza się często wielokrotnie, bo praca nad jednym
featuerem może składać się z wielu wielu pomniejszych zmian, z czego każda
zasługuje na commita.
4. Czasami chcemy wysłać zawartość swojej gałązki na Launchpada. Do tego
służy bzr push, ale pushujemy do swojej gałązki, nie do pnia.
5. Od czasu do czasu, by wprowadzić do swojej gałązki zmiany, które
dokonano w pniu od momentu gdy się rozgałęziliśmy, musimy wrosnąć pień w
naszą gałązkę.
     W tym celu (w naszej gałązce, *nie* w pniu!) wykonujemy bzr merge
[pień]. W ten sposób wszystkie zmiany jakie pojawiły się w pniu są
importowane do naszej galązki. Oczywiście, jak po każdym merge, sprawdzamy
czy wszystko działa, ewentualnie poprawiamy, i commit.
6. Gdy wprowadzimy wszystkie zmiany które chcieliśmy zrobić, i jesteśmy
zadowoleni z efektu, upewniamy się, że nie rozjechaliśmy się z pniem (tj.
wykonujemy krok 5, chyba że wiemy że nic nie trzeba importować), oraz
upewniamy się, że nasza gałązka jest wysłana na Launchpada (krok 4).
Następnie, z poziomu Launchpada zgłaszamy MergeProposal.

7. Cała ekipa dostaje na maila cynk, że został zgłoszony MP. Mamy wtedy
czas by poczytać treść proponowanych zmian, pooglądać je, skomentować,
przedyskutować, ocenić.
7b. Jeżeli okaże się, że konieczne są jakieś poprawki, zgłaszający dokonuje
ich w swojej gałązce, commit, i push (do galązki, nie do pnia!)
8. Gdy dojdziemy do wniosku, że ten MP jest fajny a zmiany są dobrej
jakości, gałązka jest gotowa do wrośnięcia w pień.

Jak wrosnąć ją w pień? Ano broń Boże bzr push [pień], nie o to chodzi (to
często komplikuje stan rzeczy).
Zamiast tego zgarniamy pień, mergujemy do niego pożądaną gałązkę (bzr merge
[gałązka]), sprawdzamy czy wszystko gra, commit, i teraz wpychamy do pnia
(bzr push [pień]).

Mam nadzieję, że taki poradnik troszkę uprości sprawę :)

PS. Opowiadałem Wam, że nie da się zrosnąć dwu gałązek, które nie mają
wspólnego korzenia, tylko różnią się od samego początku. Jednak tak nie
jest (są szanse, że to jest nowy nieznany mi dotąd ficzer w bazaarze); otóż
bazaar widzi jakby zerową rewizję w postaci kodu pustego, przez co istotnie
potrafi połączyć takie 2 gałązki, po prostu importując zmiany z jednej i
drugiej do pustego katalogu. No ma to sens. Nie przyda nam się, ale
chciałem się poprawić w tej kwestii.


W dniu 7 lipca 2013 17:41 użytkownik Qba <sequba@xxxxxxxxx> napisał:

> Z mojej strony myslę, że same polecenia i obsługa bazaara już nie stanowią
> dla mnie problemu (nie mam nic przeciwko wywaleniem już zadania
> treningowego). Natomiast (ponieważ zrobiłem kilka głupich rzeczy ostatnio),
> chciałbym prosić o jakieś praktyczne wskazówki dotyczące tego, jak robić
> niektóre rzeczy.
>
> Na przykład, przy pisaniu czegoś w osobnej gałązce:
> (popraw mnie, cielaku, jeśli się mylę) Jak już mam gotowe, to robię merga
> z trunciem, naprawiam wszystkie konflikty, commituję, ale nie pushuję
> jeszcze do trunca, tylko na launchpadzie robię MP i czekam na wasze opinie,
> tak?
>
> Sądzę, że będę miał jeszcze wiele podobnych wątpliwości, które wyjdą w
> czasie pracy, ale to chyba normalne, bo dopiero się uczę takiego trybu
> pracy...
>
> Kuba.
>
>
> 2013/7/7 Rafał Cieślak <rafalcieslak256@xxxxxxxxxx>
>
>>  Oryginalny plan był taki, abym dziś wieczorem wywalił zadanie
>> treningowe, i wstawił jakiś zalążek kodu, byśmy mogli już na serio
>> programować te wstępne prawdziwe zadania (im szybciej tym lepiej, co tracić
>> czas na taki niby-kod, jak niektórzy już mają pomysły jak się brać z coś z
>> tych prawdziwych blueprintów).
>>
>> Ale wygląda na to, że mało kto z tego treningu skorzystał. Jeśli brakło
>> Wam czasu, dajcie znać, w zależności od zainteresowania można by przedłużyć
>> termin treningu do poniedziałku czy wtorku. A jeśli się Wam po prostu nie
>> chce bawić w takie pierdółki (mimo wszystko warto jednak bazaara spróbować
>> wpierw na kodzie, którego nie będzie szkoda jakby coś schrzanić), no to też
>> spoko, w takim razie od razu się zajmiemy projektem.
>>
>> Tak więc dajcie znać jak Wam bardziej pasuje.
>>
>> --
>> Mailing list: https://launchpad.net/~millennium-dev
>> Post to     : millennium-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~millennium-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>