Najlepsze praktyki w zakresie tworzenia i używania wspólnych bibliotek w kontroli wersji?

Question

Zawsze zastanawiałem się, jak aktywnie opracowana wspólna biblioteka używana w dwóch lub więcej projektach powinna być przechowywana w kontroli wersji. Wyobrażam sobie, że można nią manipulować inaczej niż biblioteką firm trzecich, ponieważ wewnętrzna biblioteka jest bardziej skłonna do otrzymania gorących poprawek, które powinny być dystrybuowane do wielu projektów w kontroli wersji.

Czy jego pliki binarne powinny być importowane do projektów, które używają go w miarę jego aktualizacji (podobnie jak biblioteka stron trzecich), czy też jego kod źródłowy może zostać sprawdzony razem z projektami? Czy można mieć odniesienia do innych ścieżek kontrolowanych przez wersję w Subversion lub innych systemach kontroli wersji?

Pracuję nad projektem, w którym wspólne biblioteki, które znajdują się w innym miejscu w Subversion (i użyte w wielu projektach), zostały sprawdzone w projekcie, więc wszelkie zmiany wprowadzone do nich w tym projekcie nie są odzwierciedlone w ich "prawdziwych" "repozytorium. Zamierzam zasugerować pewne zmiany w tym zakresie, ale chciałbym się zastanowić, jaka jest najlepsza praktyka w posługiwaniu się tymi popularnymi bibliotekami.

Answer 1

Jak już wspomnieliśmy, dobrym pomysłem jest wykonanie SVN's externals. Za ich pośrednictwem można odwoływać się do innych części repozytorium (lub innych repozytoriów również, FTM). Projekt może odwoływać się do nagłówka innego projektu (biblioteki) lub do gałęzi lub znacznika. Te dwa ostatnie zapewniają stabilność, a ta pierwsza jest zawsze na bieżąco z biblioteką.

Widziałem różne schematy wzdłuż tej linii za pomocą CVS (bez zewnętrznych, więc to było skontrolowane skrypty, które musiały zostać wykonane) i SVN. W firmie, w której pracuję, mamy różne foldery najwyższego poziomu dla projektów i bibliotek współdzielonych. Projekty mogą odwoływać się do bibliotek. Na zewnętrznej stronie projektu odnośniki zewnętrzne zazwyczaj odnoszą się do głów bibliotek, w projektach znaczników i oddziałów odnoszą się do znaczników bibliotek (lub czasami do oddziałów).

Answer 2

Używając Subversion, użyłbym svn:externals, który pozwala na tworzenie zależności jednego repo Subversion do drugiego.

Answer 3

Subversion pozwala na posiadanie odniesień do innych ścieżek, poprzez użycie właściwości svn:externals.

To powiedziawszy, często będziesz potrzebować nieco większej kontroli nad stanem projektu, niż "weź wszystko, co jest we wspólnej głowie biblioteki". W takim przypadku sugerowałbym przypisanie skompilowanej biblioteki binarnej do każdego z pozostałych projektów, które jej używają. W ten sposób masz kontrolę nad wdrażaniem biblioteki dla każdego z jej klientów.

Answer 4

Tak.

Oddzielne "pod-biblioteki" wielokrotnego użytku w oddzielne projekty wcześniej i często.

Spójrz na praktyki open-source: większość rzeczy to wiele małych projektów, które są połączone razem.

Twórz wiele małych projektów.

Unikaj sprawdzania w plikach binarnych. Ponownie postępuj zgodnie z praktykami Open Source. Zachowaj źródło w subwersji.

Utwórz pliki binarne i umieść je w katalogu "udziału projektu" oddzielnie od źródła.

Answer 5

Właściwe narzędzie do rozwiązania tego problemu to Maven. Pierwotnie opracowany dla Javy, może być używany do dowolnego istniejącego języka programowania.

Maven tworzy repozytorium na komputerze, na którym znajdują się wszystkie moduły. Możesz także utworzyć repozytorium modułów publicznych, pozwalając innym osobom pobierać moduły z tego miejsca.

Każdy moduł ma listę zależności, które są automatycznie rozwiązywane (należy przeczytać pobrane). Na etapie budowy projektu odpowiednia wtyczka do języka programowania umieści wszystkie zależności w określonych miejscach, aby kod źródłowy mógł je zobaczyć.

Maven to świetne narzędzie wielofunkcyjne, ale bardzo trudne do opanowania, to tylko minus.

Answer 6

Zachowujemy kod ze wspólnych bibliotek w SVN w ich własnych folderach projektu. Przekazujemy również pliki binarne do innego folderu "projektu" o nazwie Zależności. Używamy svn: externals, aby wprowadzić potrzebne referencje do projektów.

Answer 7

Nie rozumiem nawet pytania. Jeśli foo zależy od libbar, dlaczego chcesz zachować źródło dla libbar w VCS foo? Łączymy z libbar lub importujemy moduł pręta, jeśli jest odpowiedni dla danego języka. Dlaczego chcesz pomieszać drzewo źródłowe dla twojego projektu? Moje "cześć, świat!" projekt zależy od libc. Podobnie jak moje "cześć, Dolly!" projekt. Żaden z projektów nie zachowuje źródła libc w bazie kodu. Aby to zrobić, byłoby szalone. Dlaczego traktować biblioteki wewnętrzne w inny sposób niż biblioteki stron trzecich w tym zakresie? Krótko mówiąc, najlepszą praktyką jest: nie rób tego. Jeśli Twoja biblioteka ma poprawki hot-ass, które trzeba propagować do swoich projektów, użyj dynamicznego powiązania.