Używanie SVN z wieloma wersjami rozwojowymi

Question

Mój zespół używa SVN do zarządzania kontrolą swojego źródła. Otrzymałem zadanie sprawdzenia, czy istnieje jakakolwiek poprawa sposobu, w jaki używamy SVN.

Przeczytałem wiele książek o SVN i zrobiłem wiele badań nad tym, jak inni używają SVN.

Mam zamiar dać przegląd, jak używamy svn i mam nadzieję, że ktoś ma kilka sugestii dla mnie.

Przede wszystkim mamy wydanie co miesiąc lub dwa. Obecnie używamy pnia jako naszej kopii produkcyjnej kodu i tworzymy gałąź wydania dla każdego zaplanowanego dostarczania i dla każdej poprawki produkcyjnej.

Zwykle mamy dwie, czasami trzy zaplanowane dostawy w tym samym czasie. Na przykład mogę kodować wydanie 3, ale ja lub inni testujemy wersję 2 i robimy końcowe poprawki dla wydania 1. Może również występować jednocześnie naprawa produkcyjna.

W tej chwili wykonujemy wiele scaleń, aby zachować synchronizację gałęzi (każdego wydania). Wersja 3 wymaga kodu z 2 i 1, ale oczywiście nie chcemy, aby nowy kod z wydania 3 trafił do wersji 1. Tak więc chcielibyśmy przeprowadzić serię scaleń od wersji 1 do wersji 2 i od wersji 2 do wersji 3. musiałyby być regularnie powtarzane, aby kodery w wersji 3 miały poprawki z 2 lub 1.

Ilekroć wprowadzana jest poprawka lub poprawka produkcyjna, scalamy kod z powrotem w bagażniku. Następnie łączymy go z pnia (lub gałęzi zwalniającej, która właśnie trafiła do produkcji) we wszystkie aktywne gałęzie.

Jak można zauważyć, spędzamy dużo czasu na łączeniu.

To dużo pracy dla osoby kontrolującej kontrolę źródła. Ciągle robią fuzje i upewniają się, że śledzą, które filie są połączone w miejscu.

Wygląda na to, że SVN jako nasz system zarządzania kontrolą źródła (wiem, że to naprawdę tylko kontrola wersji, ale używamy go do zarządzania naszą kontrolą źródła) powinien nam w tym pomóc.

Na przykład byłoby wspaniale, gdyby programista pracujący nad wydaniem 3 wiedział, kiedy coś zmieniło się w wersji 2, wydaniu 1 lub w kufrze, a programista mógł zostać automatycznie powiadomiony i mógł wykonać scalenie, aby wprowadzić zmiany w jego oddział. Ale zamiast tego ktoś musi wiedzieć, aby wykonać wszystkie scalenia ręcznie ... Wygląda na to, że człowiek robi zbyt wiele pracy i maszyna nie robi wystarczająco dużo.

Czy ktoś ma pomysły na to, w jaki sposób możemy lepiej wykorzystać funkcje SVN, abyśmy mogli zaoszczędzić sobie trochę tego bólu głowy i upewnić się, że wszyscy zawsze pracują z wersjami kodu, które mają być!

Dzięki!

Answer 1

Nie wiem, czy można realistycznie opracować taką sytuację za pomocą pytań i odpowiedzi na forum. Najlepszym rozwiązaniem może być skorzystanie z usług profesjonalnych od firmy takiej jak mój pracodawca, CollabNet. Subversion Training Options

Odłóżmy na chwilę takie nazwy jak "bagażnik", ponieważ te rzeczy oznaczają to, co chcesz, żeby oznaczały. Jestem jednym z entuzjastów Apache Subversion i polecam robić programowanie trochę tak, jak robimy to dla samej Subversion.

1. Praktycznie cały rozwój odbywa się w jednym miejscu, które nazywamy trunkem, ale można go nazwać "programowaniem" lub "niestabilnym" lub dowolną nazwą.
2. Niektóre prace nad nowymi funkcjami będą wykonywane na gałęziach obiektów utworzonych z pnia. Zwykle są one krótkotrwałe i zależą od autora. Staramy się, aby nasz bagaż był stabilny przez cały czas (wszystkie testy mijają), więc czasami ludzie chcą najpierw spróbować zakłócających zmian w oddziale.
3. W pewnym momencie, myślimy, że bagażnik ma funkcje, które chcemy, do momentu, w którym nadszedł czas wydania, więc gałąź wydania jest tworzona przez kopiowanie pnia.
4. Nie zezwalamy na rozwój w gałęzi wydania. Błędy są naprawiane w pniu, a rewizje zawierające poprawkę są nominowane do backportu do jednego lub więcej wydań. W przypadku zatwierdzenia, wersja (wersje) są scalane z gałęziami wydania, dla których zostały zatwierdzone.
5. Czasami pnia oddzieliła się wystarczająco od wydania, że ​​poprawka nie zostanie scalona w czysty sposób. Gdy tak się stanie, tworzymy gałąź gałęzi wstecznej, kopiując gałąź wydania, a następnie łącząc poprawkę z magistrali do gałęzi gałęzi. Dzięki temu programista może odpowiednio rozwiązać konflikty scalania w oddziale i innych programistach, aby odpowiednio sprawdzić i zagłosować na to, czy błąd powinien zostać przeniesiony.

Ten model działa dobrze, ponieważ zmiany zawsze łączą się tylko w jednym kierunku i nie musisz się martwić, że ktoś wprowadzi szybką korektę dla niektórych wersji, a następnie zapomniał wykonać tę samą poprawkę w bagażniku. Tak więc błąd nie pojawia się w następnym wydaniu.

Podkreślę, że rozwój Subversion jest dość liniowy. Nie mamy 3 wersji w locie, jak wskazano powyżej. Wciąż obsługujemy 3 wydania na raz, ale liczba obsługiwanych poprawek jest niewielka. Myślę, że ten proces mógłby działać na rzecz bardziej płynnego środowiska, takiego jak opisujesz, ale myślę, że lepiej byłoby mieć specjalistę od usług, który będzie pracował z większą dokładnością, próbując go rozwiązać.