Używanie Subversion jako repozytorium artefaktów w porównaniu z konkretnym narzędziem do zarządzania artefaktami

TL; DR: Dlaczego warto używać czegoś takiego jak Apache Archiva lub Sonatype Nexus jako repozytorium artefaktów zamiast Subversion?

System kompilacji, którego używam, ma obecnie wiele binarnych obiektów blob (obrazy, pliki dźwiękowe, skompilowane pliki binarne itp.), Zarówno jako dane wejściowe, jak i wyjściowe do naszych kompilacji. Nasz system zarządzania nimi jest bardzo ad hoc; niektóre są sprawdzane w naszym repozytorium Subversion wraz z naszym kodem, inne są przechowywane gdzie indziej poza formalną kontrolą wersji.

Staram się to skonsolidować, więc mamy coś bardziej spójnego i łatwego w użyciu, które oddziela binarne artefakty od kodu.

Google mówi mi, że dostępnych jest kilka repozytoriów artefaktów ( Archiva , Nexus , Artifactory ,…), ale po przeczytaniu nie widzę żadnej przewagi nad korzystaniem z nich w stosunku do Subversion. To zajmie się dla nas plikami binarnymi - już to robi dla niektórych naszych plików binarnych, chcielibyśmy po prostu zmienić układ repozytorium, aby oddzielić je od kodu - i ma znaczącą zaletę, że mamy już serwery Subversion i wiedzę specjalistyczną.

Więc. Jaka jest zaleta korzystania z dedykowanego systemu zarządzania artefaktami w porównaniu z ogólnym narzędziem kontroli wersji, takim jak Subversion?

svn dependency-management

— ja i
źródło

Zdecydowanie największą zaletą korzystania z dedykowanego narzędzia jest to, że inne narzędzia wiedzą, jak sobie z nimi poradzić ! Mogą umieszczać artefakty w tych narzędziach i mogą zabierać je z powrotem w sposób zautomatyzowany.

— Joachim Sauer

patrz także: programmers.stackexchange.com/questions/261751/…

— amfibia

Odpowiedzi:

Krótka odpowiedź: generalnie nie potrzebujesz historii binarnych artefaktów i zmian w tych artefaktach, potrzebujesz tylko konkretnych wersji.

Dłuższa odpowiedź: za każdym razem, gdy dokonujesz niewielkiej zmiany w pliku binarnym, systemy kontroli wersji nie mają możliwości utworzenia delty - różnicy między tymi dwoma plikami - więc tworzy ona zupełnie nową kopię.

W CVCS, takim jak SVN, nie jest to tak duży problem, ponieważ masz tylko jedną centralną kopię swojego repozytorium - twoja lokalna kopia to tylko jedna wersja. (Chociaż nawet wtedy Twoje repozytorium może stać się bardzo duże, co spowalnia proces sprawdzania.) Ale co się stanie, jeśli później przełączysz się na DVCS, w którym każda kopia repozytorium ma pełną historię każdego pliku? Rozmiar zmian staje się bardzo istotny.

A co ci daje w zamian za ból? Jedyne, co oferuje, to możliwość powrotu do poprzedniej wersji repozytorium i wiedza, że masz odpowiednie pliki binarne dla tej wersji.

Ale czy potrzebujesz do tego całego pliku binarnego w repozytorium? A może po prostu masz plik tekstowy informujący proces kompilacji, które wersje pobrać z innego repozytorium w innym miejscu?

To ostatnie jest ogólnie oferowane przez repozytoria artefaktów.

Ponadto niektóre bardziej profesjonalne, takie jak Nexus, dostarczą również informacji na temat licencjonowania artefaktów innych firm, abyś nie ryzykował subtelną klauzulą w tym, co uważasz za bibliotekę FOSS.

— pdr
źródło

Ok, powinienem unikać używania mojego obecnego repozytorium Subversion jako repozytorium artefaktów, ale dlaczego nie założyć nowego repozytorium Subversion? Wydaje się, że ma te same zalety i wady; repozytorium artefaktów prawdopodobnie miałoby takie same problemy z przechowywaniem dużych danych binarnych.

— me_i

@me_and: Możesz to zrobić. Ale musisz zarządzać, która wersja zapewnia wersję artefaktu. Po co sobie dawać dodatkową pracę, gdy repozytorium artefaktów robi to za Ciebie? To tak, jakby powiedzieć: „Więc mógłbym użyć Notatnika do napisania kodu? Po co więc zawracać sobie głowę Eclipse?” Ponadto nigdy nie będziesz w stanie naprawdę usunąć starych wersji, aby zaoszczędzić miejsce. Możesz to zrobić dzięki repozytorium artefaktów.

— pdr

Aby podkreślić i rozszerzyć odpowiedź o @pdr, jeśli użyjesz svn jako repozytorium binarnych artefaktów, prawdopodobnie wystąpią problemy z pamięcią masową, ponieważ svn jest zaprojektowany tak, aby nigdy nie usuwać danych. W jednym miejscu, w którym pracowałem, używaliśmy svn do przechowywania artefaktów i regularnie przekraczaliśmy limity przechowywania, ponieważ usunięcie starych nieużywanych artefaktów ze sklepu było trudne (nie niemożliwe, ale trudne). Natywne narzędzia repozytorium binarnego, takie jak Artifactory i Nexus, umożliwiają usuwanie niepotrzebnych artefaktów.

— Matthew Skelton,

Korekta: Subversion korzysta wewnętrznie z binarnych delt (i tylko AFAIK). Wiele lat temu eksperymentowałem z przechowywaniem plików MS Office i było to bardzo skuteczne. Rozmiar repozytorium zwiększał się bardzo powoli, nawet przy intensywnym tasowaniu 200 slajdów programu PowerPoint. Ale skuteczność algorytmu binarnego delta będzie się znacznie różnić w zależności od typu pliku i myślę, że prawdziwym problemem jest brak zasad przechowywania (coś, co można obejść z filtrowanym zrzutem / obciążeniem, ale wtedy zaczniesz pisać własne rozwiązanie).

— Peter Becker

„systemy kontroli wersji nie mają żadnego sposobu na utworzenie delty” - problem polega na tym, że właśnie to robią - od 2006 ... subversion.apache.org/docs/release-notes/1.4.html#svndiff1 en.wikipedia. org / wiki / Xdelta

— RnR

Używamy SVN jako repozytorium kompilacji wersji i robi to bardzo dobrze. Mamy w jednym repozytorium wydań ponad 30 GB różnych wersji wydań i dobrze się sprawdza, wyciągając kompilacje do wdrożenia.

niektóre zalety tego są ..

Pliki binarne dodane do SVN są skompresowane o prawie 60-70 procent w celu zaoszczędzenia miejsca.
SVN służy jako biblioteka (sztuczna) dla wydań, a kopia zapasowa repozytorium na potrzeby odzyskiwania po awarii.
SVN przez https pozwala na bezpieczne dostarczanie kodu wersji do DMZ.

— Lance Lyons
źródło