Myślisz, że zarabiasz tyle, na ile zasługujesz? Zapraszamy do wzięcia udziału w anonimowej ankiecie.
0

1

Witam,

Na początku wybaczcie za zpolszczanie angielskich słów ;-)

Od dłuższego czasu używam SVN poprzez TortoiseSVN i jestem bardzo zadowolony. Początkowo używałem tylko podstawowej funkcji Commit i Update do gałęzi trunk. Jak wiadomo takie podejście będzie powodowało dużo problemów jak wiele ludzi będzie wprowadzało swoje zmiany i co chwilę robiło Commit.

W takich przypadkach należy używać Branch'y i tak też robie ;-)

Problem pojawia mi się przy mergowaniu trunka z moim branchem i w drugą stronę mojego brancha z trunkiem.

Załóżmy taki scenariusz że tworzę brancha i na nim przeprowadzam zmiany. Ktoś inny w tym czasie robi zmiany w Trunk. Co pewien czas należy więc wprowadzić zmiany z Trunk do swojego Brancha żeby potem można było łatwo zintegrować spowrotem mojego brancha z trunkiem oraz żeby nie popsuć zmian kogoś innego. Jakich komend TortoiseSVN należy użyć? a) Merge a range of revisions b) Reintegrate a branch c) Merge two different trees

Chodzi mi o kilka przyapadków:

1) gdy chcę do mojego brancha na którym obecnie pracuje wciągnąć HEAD z trunka 2) gdy chcę do trunka wciągnąć mojego brancha i dalej pracować na branchu

Do tej pory korystałem z opcji a) i b) ale nia pamiętem przy którym z nich często pojawiały mi się konflikty drzewa i trzeba było podać czy ma używać mojej lokalnej kopii czy pliku z repo.

Pozdrawiam

flag

3 Answers

2

jeżeli chcesz dodać zmiany dokonane na gałęzi trunk do swojej gałęzi to korzystasz z "Merge a range of revisions"

Z "Reintegrate branch" korzystasz, gdy chcesz zmiany z brancha wpuścić do trunka i TYLKO wtedy, kiedy branch jest zsynchronizowany z trunkiem (e.g. wszystkie zmiany z trunka zostały dodane do brancha)

Trzeciej opcji używasz gdy chcesz scalić zmiany z brancha jednak gałęzie nie są z sobą zsynchronizowane.

Konflikty są raczej nieuniknione - można je jednak ograniczyć. Patrz poniżej:

Mała adnotacja: podczas korzystania z svn'a warto korzystać ze skryptu svnmereg.py, który samodzielnie zadba o mergowanie gałęzi. Chcesz dodać zmiany z trunka do Twojej gałęzi: svnmerge merge -S truk. Chcesz scalić zmiany z gałęzi do trunka: svnmerge merge -S branch_name Polecam.

No i warto rezygnować z SVNa jeżeli zaczynamy nowy projekt. Mercurial, ew GIT i jazda.

link|flag
Zarówno Mercurial jak i Git są zupełnie innymi systemami niż SVN i nie ma co ich używać zamiennie. Główna różnica jest taka, że Git jest modny ;) Trochę jak z HTML vs XHTML. – Maciej Łebkowski Jan 21 at 19:08
wspomniałem o zastąpieniu svna przez gita lub mercuriala (lub inny DVCS) a nie o używaniu ich zamiennie. Git nie jest modny bez powodu - tak samo jak kiedys svn nie był modny bez powodu. Tak już jest, że świat idzie do przodu i powstają narzędzia poprawiające błędy poprzedników – matekm Jan 22 at 9:28
"Z "Reintegrate branch" korzystasz, gdy chcesz zmiany z brancha wpuścić do trunka i TYLKO wtedy, kiedy branch jest zsynchronizowany z trunkiem (e.g. wszystkie zmiany z trunka zostały dodane do brancha)" No ale przecież nigdy nie mam takiej gwarancji że mój branch jest połaczony z HEAD trunka. W trakie jak ja robiłem aktualizacje brancha to ktoś mógł robić zmiany w trunk. Coś mi tu nie gra – bodziec Jan 25 at 13:31
oczywiście, że mógł - w takim przypadku ta operacja się nie powiedzie. Zajrzyj do dokumentacji: tortoisesvn.net/docs/nightly/TortoiseSVN_en/… – matekm Jan 25 at 14:16
1

Kilka dobrych praktyk:

  1. Jeżeli robisz brancha to należy zablokować (lock) pliki w trunku. Tak, żeby nikt nie zepsuł ci kodu.
  2. Jeżeli możesz to branchujesz tylko moduł, a nie cały projekt.
  3. Zawsze merge jest branch do trunk. Na odwrót tylko w przypadkach kryzysowych lub gdy nie można podzielić projektu na moduły. Przy czym najpierw trunk do branch, a potem branch do trunk.
  4. Po zakończeniu mergowania ściągnij cały projekt z trunka, skompiluj i przetestuj. Może zdarzyć się tak, że w trunku pozostaną jakieś śmieci, które należy wywalić ręcznie, bo mergowanie nie zawsze potrafi sobie z tym poradzić.

Kilka moich obserwacji

  • plik usunięty w branchu po zmergowaniu branch do trunk nadal leży w trunku.
  • warto rozgłaszać, że mergujesz repo, by inni nie grzebali razem z tobą w tym samym czasie.
link|flag
"Jeżeli robisz brancha to należy zablokować (lock) pliki w trunku" - WTH? Po co robić branch, skoro blokujesz możliwość zmian w głównej gałęzi. Branche są właśnie po to, żeby inni mogli spokojnie pracować, gdy ty robisz jakieś większe zmiany i nie chcesz przeszkadzać. – lqc Jan 21 at 12:13
Z prostej przyczyny. Jeżeli robisz brancha to zakładasz, że pliki z trunka i tak się zmienią. Najgorsze co może się stać to mergowanie tego samego pliku z trunka i brancha. Jeżeli zachodzi konieczność szybkiej zmiany błędu krytycznego to osoba odpowiedzialna brancha musi uczestniczyć w tym procesie i musi wprowadzić od razu zmiany w branchu. – Koziołek Jan 21 at 12:28
Czyli żeby poprawić krytyczny błąd, muszę się skontaktować z właścicielem brancha, który jest na przykład na urlopie w Tunezji. To rzeczywiście bardzo wygodne. Właściciel brancha, może sobie nałożyć fix później - jego kod i tak jest pewnie rozgrzebany i nie można go uruchomić. – lqc Jan 21 at 12:44
Dlatego nie powinno być sytuacji, że "nie ma haseł", "nie ma odpowiedzialnych". – Koziołek Jan 21 at 15:04
1

Robienie równoległych zmian nie powoduję żadnych problemów dopóki nie robicie zmian w tym samym pliku, w tych samych liniach (to jeszcze zależy od algorytmu złączania).

Podstawowy tryb pracy z SVN, to:

  1. Zrób zmiany.
  2. Przetestuj, że twoje zmiany nie psują programu.
  3. Zrób update.
  4. Złącz swoje zmiany ze zmianami innych (jeśli wystąpi taka konieczność)
  5. Zrób commit.

Jeśli robisz dłuższe i skomplikowane zmiany, to wtedy chcesz mieć branch dla tych zmian, tak żeby móc robić commit nie martwiąc się czy przypadkiem właśnie nie popsułeś wszystkiego i inni nie będą mogli przez ciebie pracować.

Po drodzę, możesz chcieć uaktualnić swój branch jakimiś zmianami z trunk'a (pewnie bugfixy). Wtedy chcesz wybrać te interesujące cię zmiany i przenieść tylko je do swojej gałęzi. Do tego używasz opcji a).

Jak skończy pracować nad swoimi zmianami, testujesz i łączysz zmiany z główną gałęzią używając opcji c).

Występowanie konfliktów w złączeniach jest naturalne i należy je rozwiązywać. Nie koniecznie tylko wybierając, którą wersja całości jest właściwa. Zazwyczaj wymaga to edycji.

link|flag

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.