Szukam ogólnego przeglądu różnych zasad kontroli kodu źródłowego. Natknąłem się tylko na zasady obowiązujące w Main-Line i chciałbym lepiej poznać innych, zanim zdecydują się na współpracę z zespołem.Zasady kontroli kodu źródłowego
Czy ktoś może podać link do przeglądu, czy nawet podać mi nazwy zasad, abym mógł uruchomić google?
Papier jest doskonałą dyskusją na temat rozgałęzień, takich jak wzorzec "głównej linii", o którym wspominasz - wymienia opcje w postaci wzorów wraz z omówieniem anty-wzorców. Jednym z autorów jest Robert Orenstein z firmy Perforce.
Mój ulubiony polityka brzmi „Nie popełnia Subversion, które nie odwoływać bilety + Auto Trac komentarzy dla każdego popełnić”: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
Być może, ale tylko może, w naprawdę zamknięte środowisko konserwacji. Wolałbym, aby wszyscy deweloperzy byli zachęcani do odprawy. Uzyskaj zautomatyzowany system testowania i tworzenia i upewnij się, że masz kontrole konfiguracji dla linii bazowych, ale nie zniechęcaj do zatwierdzania. –
miałem świetny użytek z książki Practical Perforce. Choć może nie pracujesz z Perforce, myślę, że rozdział 7 (Jak rozwija się oprogramowanie) i rozdział 8 (Podstawowe zarządzanie linią Codeline) może być bardzo przydatny. Możesz je odtworzyć na Google Books.
Perforce ma również wiele świetnych artykułów na ten temat. Software Life-Cycle Modeling pisze o zasadach.
Perforce complete technical documentation.
I, nie, nie pracuję ani na Perforce.
Powodzenia Thomas
Brak pustych Wiadomości commit.
Zatwierdzanie na zmianę zamiast na plik.
to ma następujące zalety:
Niektórzy uważają, że ta polityka powoduje więcej zatwierdzeń, ale z mojego doświadczenia wynika, że masz mniej zobowiązań. Na przykład robisz refaktoryzację, która wpływa na 50 plików. Po refaktoryzacji masz jedno zatwierdzenie z komunikatem "Refaktoryzowany podsystem xyz.".
W przypadku większych zmian należy wziąć pod uwagę następujące zasady: dev-branch-per-change.
Powoduje to bardzo dużo błędów, czy nie? Czy potrafisz nazwać system kontroli kodu źródłowego, który obsługuje ten rodzaj polityki. Wszystkie systemy, które znam, obsługują tylko commit dla pliku. – boutta
Tak, to dużo błędów. Dopóki są one prawdziwe (http://thedailywtf.com/Articles/Productivity-20.aspx), nie stanowi to problemu @Vilmantas Baranauskas chce mieć pewność, że potrafi śledzić, do czego służą poszczególne poprawki. To kompromis. –
Subversion to obsługuje. Na przykład. pracujesz nad błędem # 123. Aby naprawić ten błąd, musisz zmienić 10 plików. Kiedy skończysz, w katalogu głównym drzewa źródłowego zatwierdzasz: svn commit -m "Naprawiono błąd # 123.". Modyfikacja 10 plików jest zatwierdzana jako pojedyncze zatwierdzenie z pojedynczą wiadomością. –
Nie należy rejestrować/zatwierdzać żadnych zmian, które powodują uszkodzenie kompilacji.
Używamy kilku praktycznych zasad jako zasad zatwierdzania w naszym projekcie. Te zasady pomagają nam zachować każdą wersję w stanie gotowości do wdrożenia. Nasze zasady są podobne do zasad zatwierdzania KDE, opublikowanych tutaj: http://techbase.kde.org/Policies/SVN_Commit_Policy. Każdy popełnić należy (od wyższego do niższego priorytetu):
Opracowaliśmy proste narzędzie SvnCommitChecker, które pomoże nam sprawdzić niektóre z tych zasad przed zatwierdzeniem svn. Mam zamiar umieścić go na stronie sourceforge w najbliższej przyszłości z artykułem o korzyściach z utrzymywania dobrej historii zmian svn.
Te dwa są zasadniczo takie same:
Version Control for Multiple Agile Teams
Configuration Management Branching Strategy
Używamy tej strategii, aby tułów stabilny i umożliwiają programistom zrobić cokolwiek, czego potrzebują w swoich oddziałach.
Jest jakiś problem z Subversion, ponieważ nie może obsługiwać Cyclic merges ale można go obejść poprzez usunięcie gałęzi rozwojowej po każdym powrocie z powrotem do bagażnika (bez znaczenia dla innych systemów kontroli wersji)
Link nie działa. Myślę, że to jest właściwy: www.hillside.net/plop/plop98/final_submissions/P37.doc – Nippysaurus