Dlaczego systemy kontroli źródła są nadal w większości wspierane plikami?

22

Wygląda na to, że więcej systemów kontroli źródła nadal wykorzystuje pliki jako sposób przechowywania danych wersji. Vault i TFS używają Sql Server jako magazynu danych, co moim zdaniem byłoby lepsze zarówno pod względem spójności danych, jak i szybkości.

Dlaczego więc SVN, jak sądzę, GIT, CVS itp. Nadal używa systemu plików jako zasadniczo bazy danych (zadaję to pytanie, ponieważ nasz serwer SVN właśnie się zepsuł podczas normalnego zatwierdzania) zamiast korzystania z rzeczywistego oprogramowania bazy danych ( MSSQL, Oracle, Postgre itp.)?

EDYCJA: Myślę, że innym sposobem zadania mojego pytania jest „dlaczego programiści VCS wprowadzają własny system przechowywania danych strukturalnych zamiast używać istniejącego?”

version-control Andy
źródło
29
Jak myślisz, czego większość baz danych używa jako podstawowego zaplecza? Większość korzysta z plików (niektóre korzystają jednak z bezpośredniego dostępu do dysków twardych). Możesz mieć wszystkie funkcje bazy danych, używając „tylko plików”.
Joachim Sauer
2
@JoachimSauer Fair point, choć oczywiście wtedy trzeba by było stworzyć bazę danych. Co jest głupie, jeśli pożądany zestaw funkcji jest zbliżony do istniejących rozwiązań i nie ma bardzo dobrych powodów, aby nie używać żadnego z nich.
1
@ JoachimSauer Tak, zdaję sobie z tego sprawę, ale systemy DBM mają sposoby na zapewnienie, że nic niespójnego nie dostanie się do bazy danych. O ile repozytoria oparte na plikach nie używają czegoś takiego jak Transactional NTSF, nadal istnieje możliwość uszkodzenia. I ufam prawdziwej bazie danych bardziej niż zespołowi programistów, którzy w zasadzie na nowo wynajdują koło, ponieważ myślę, że możemy się zgodzić, że systemy kontroli źródła wymagają integralności danych.
Andy,
2
@delnan Wsparcie transakcyjne i spójność wewnętrzna. Teraz przywracamy nasze repozytorium SVN z taśmy b / c serwer SVN nie zapisał poprawnie wszystkich plików, które powinien. Przeszukuje również ogromne ilości danych. Chodzi mi o to, dlaczego warto wynaleźć koło na nowo.
Andy
7
Każdy większy system operacyjny ma wbudowany system plików. Wszystkie te systemy plików mają tę samą podstawową funkcjonalność (pliki, foldery, trwałość). Zasadniczo baza danych to jedna dodatkowa zależność, którą użytkownik końcowy musi zainstalować i aktualizować. Kontrola źródła nie jest podstawową działalnością większości ludzi (chyba że jesteś sourceforge lub github). VC jest często instalowany na serwerach za pośrednictwem wiersza polecenia przez najnowszego członka zespołu. Ważna jest łatwość instalacji i konfiguracji.
GlenPeterson

Odpowiedzi:

23

TL; DR: Niewiele systemów kontroli wersji korzysta z bazy danych, ponieważ nie jest to konieczne.

Jako pytanie do odpowiedzi na pytanie, dlaczego nie mieliby? Jakie zalety oferują „rzeczywiste” systemy baz danych w porównaniu z systemem plików w tym kontekście?

Weź pod uwagę, że kontrola wersji polega głównie na śledzeniu niewielkich metadanych i wielu różnic tekstowych. Tekst nie jest przechowywany w bazach danych bardziej wydajnie, a indeksowalność treści nie będzie czynnikiem.

Załóżmy, że Git (ze względu na argument) użył BDB lub SQLite DB dla swojego zaplecza do przechowywania danych. Co byłoby bardziej wiarygodne? Wszystko, co może uszkodzić proste pliki, może również uszkodzić bazę danych (ponieważ jest to również prosty plik z bardziej złożonym kodowaniem).

Z paradygmatu programisty polegającego na nieoptymalizowaniu, chyba że jest to konieczne, jeśli system kontroli wersji jest wystarczająco szybki i działa wystarczająco niezawodnie, po co zmieniać cały projekt na bardziej złożony?

mikebabcock
źródło
2
TLDR? Twoja odpowiedź była dwa razy dłuższa, a pytanie było naprawdę krótkie!
Brad
25
@Brad Trzy następujące po nim słowa TL;DRto skrócona wersja odpowiedzi, a nie stwierdzenie, że pytanie jest za długie i nie przeczytał go przed odpowiedzią.
6
@Andy Mercurial ma również „grep w historii” i git prawdopodobnie również to ma. Już teraz jest błyskawiczny. Jeśli chodzi o pozostawienie rzeczy ekspertowi: ludzie, którzy opracowują VCS, są ekspertami.
3
Chcę tylko dodać, że rozumiem twój punkt widzenia; jeśli VCS zapisuje złe dane, nie ma znaczenia, czy zapisuje je do pliku lub bazy danych. Drugą stroną jest to, że repozytorium oparte na plikach prawdopodobnie zapisuje do więcej niż jednego pliku na raz i zwykle nie obsługuje tego transakcja, więc jeśli jeden plik zapisuje, ale inny się nie powiedzie, twój VCS jest teraz uszkodzony, a tablica wieloznaczna zapisuje w bazie danych transakcja zostanie zatwierdzona jako niepowodzenie jako jednostka. Wydaje mi się, że grupa programistów tworzących oprogramowanie baz danych ma z tym więcej doświadczenia niż ludzie piszący SVN ... ale może się mylę.
Andy,
6
Twój wybór git „ze względu na argument” jest tutaj ważny: git ma bardzo dobry model do pisania swoich obiektów, ale wiele narzędzi tego nie robi. W przypadku git, jeśli komputer jest wyłączony w środku zatwierdzenia, zapisujesz niektóre obiekty w systemie plików i będą one po prostu niedostępne. W przypadku innych VCS możesz dodać zmiany do połowy plików (i dochodzi do zamieszania). Można argumentować, że inne narzędzia kontroli wersji są źle zaprojektowane (i miałbyś rację), ale kiedy piszesz VCS, o wiele łatwiej jest po prostu użyć transakcji SQL i pozwolić, aby działała poprawnie.
Edward Thomson,
25

Wygląda na to, że przyjmujesz wiele założeń, być może opartych na twoim doświadczeniu z SVN i CVS.

Git i Mercurial są w zasadzie jak SVN i CVS

Porównanie git i CVS jest jak porównanie iPada i Atari. CVS powstał, gdy dinoaury wędrowały po Ziemi . Subversion jest w zasadzie ulepszoną wersją CVS. Zakładanie, że nowoczesne systemy kontroli wersji, takie jak git i Mercurial, działają jak one, nie ma większego sensu.

Relacyjna baza danych jest bardziej wydajna niż baza jednofunkcyjna

Czemu? Relacyjne bazy danych są naprawdę skomplikowane i mogą nie być tak wydajne jak bazy danych do jednego celu. Niektóre różnice z czubka mojej głowy:

  • Systemy kontroli wersji nie wymagają skomplikowanego blokowania, ponieważ i tak nie można wykonać wielu zatwierdzeń jednocześnie.
  • Rozproszone systemy kontroli wersji muszą być bardzo oszczędne pod względem miejsca, ponieważ lokalna baza danych jest pełną kopią repozytorium.
  • Systemy kontroli wersji muszą wyszukiwać dane tylko na kilka konkretnych sposobów (według autora, identyfikatora wersji, czasami wyszukiwania pełnotekstowego). Tworzenie własnej bazy danych, która może obsługiwać wyszukiwanie autorów / numerów identyfikacyjnych wersji, jest banalne, a wyszukiwanie pełnotekstowe nie jest bardzo szybkie w żadnej relacyjnej bazie danych, którą próbowałem.
  • Systemy kontroli wersji muszą działać na wielu platformach. Utrudnia to korzystanie z bazy danych, którą należy zainstalować i uruchomić jako usługę (np. MySQL lub PostgreSQL).
  • Systemy kontroli wersji na twoim komputerze lokalnym muszą działać tylko wtedy, gdy coś robisz (np. Zatwierdzenie). Pozostawienie usługi takiej jak MySQL działającej cały czas na wypadek, gdybyś chciał dokonać zatwierdzenia, jest marnotrawstwem.
  • W większości systemy kontroli wersji nigdy nie chcą usuwać historii, wystarczy do niej dołączyć. Może to prowadzić do różnych optymalizacji i różnych metod ochrony integralności.

Relacyjne bazy danych są bezpieczniejsze

Znowu dlaczego? Wydaje się, że zakładasz, że ponieważ dane są przechowywane w plikach, systemy kontroli wersji takie jak git i Mercurial nie mają atomowych zatwierdzeń , ale mają. Relacyjne bazy danych przechowują również swoje bazy danych jako pliki. Warto zauważyć, że CVS nie wykonuje atomowych zmian, ale prawdopodobnie dzieje się tak dlatego, że pochodzą z epoki ciemności, a nie dlatego, że nie używają relacyjnych baz danych.

Istnieje również problem ochrony danych przed uszkodzeniem, gdy znajdą się w bazie danych, i znowu odpowiedź jest taka sama. Jeśli system plików jest uszkodzony, nie ma znaczenia, której bazy danych używasz. Jeśli system plików nie jest uszkodzony, silnik bazy danych może być uszkodzony. Nie rozumiem, dlaczego baza danych kontroli wersji byłaby na to bardziej podatna niż relacyjna baza danych.

Argumentowałbym, że rozproszone systemy kontroli wersji (takie jak git i Mercurial) lepiej chronią bazę danych niż scentralizowana kontrola wersji, ponieważ można przywrócić całe repo z dowolnego klonu. Jeśli więc centralny serwer spontanicznie się zapali, wraz ze wszystkimi kopiami zapasowymi, możesz go przywrócić, uruchamiając go git initna nowym serwerze, a następnie git pushz dowolnego komputera programisty .

Ponowne wynalezienie koła jest złe

Tylko dlatego, że można używać relacyjnej bazy danych dla każdego problemu składowania nie znaczy, że powinniśmy . Dlaczego korzystasz z plików konfiguracyjnych zamiast relacyjnej bazy danych? Po co przechowywać obrazy w systemie plików, skoro można przechowywać dane w relacyjnej bazie danych? Po co trzymać kod w systemie plików, skoro można go przechowywać w relacyjnej bazie danych?

„Jeśli masz tylko młotek, wszystko wygląda jak gwóźdź”.

Istnieje również fakt, że projekty open source mogą pozwolić sobie na wynalezienie koła, gdy tylko jest to wygodne, ponieważ nie masz takich samych ograniczeń zasobów, jakie mają projekty komercyjne. Jeśli masz wolontariusza, który jest ekspertem w tworzeniu baz danych, to dlaczego nie skorzystać z nich?

Co do tego, dlaczego mielibyśmy ufać autorom systemów kontroli wersji, aby wiedzieli, co robią. Nie mogę mówić w imieniu innych VCS, ale jestem całkiem pewien, że Linus Torvalds rozumie systemy plików .

Dlaczego zatem niektóre komercyjne systemy kontroli wersji używają relacyjnej bazy danych?

Najprawdopodobniej niektóre kombinacje następujących elementów:

  • Niektórzy programiści nie chcą pisać baz danych.
  • Twórcy komercyjnych systemów kontroli wersji mają ograniczenia czasowe i zasobowe, więc nie mogą sobie pozwolić na napisanie bazy danych, gdy mają już coś zbliżonego do tego, czego chcą. Poza tym programiści są kosztowni, a programiści baz danych (podobnie jak ludzie, którzy piszą bazy danych) są prawdopodobnie drożsi, ponieważ większość ludzi nie ma takiego doświadczenia.
  • Użytkownicy komercyjnych systemów kontroli wersji rzadziej troszczą się o koszty związane z konfiguracją i uruchomieniem relacyjnej bazy danych, ponieważ już ją mają.
  • Użytkownicy komercyjnych systemów kontroli wersji jest bardziej prawdopodobne, aby chciał relacyjnej bazy danych, tworzenie kopii ich rewizji, ponieważ może to zintegrować z ich procesów lepiej (jak na przykład tworzenie kopii zapasowych).
Przywróć Monikę
źródło
1
Jedno: zatwierdzenia SVN są atomowe. W rzeczywistości jest to główny argument sprzedażowy (a przynajmniej był w czasach, gdy musieli przekonać użytkowników CSV do zmiany).
1
@delnan - Zauważ, że istnieje duża różnica między teoretyczną atomicznością, którą otrzymujesz, gdy svnróżne katalogi w twoim katalogu roboczym mogą znajdować się w różnych svnwersjach, a prawdziwą atomicznością w całym repozytorium, którą otrzymujesz z gitlub hg.
Mark Booth,
2
@ Andy Chodzi mi o to, że możesz obsłużyć te same scenariusze bez pełnej relacyjnej bazy danych. Jeśli dwie osoby popełnią błąd dokładnie w tym samym czasie, serwer może zrobić jedną po drugiej. To nie jest skomplikowana funkcja do wdrożenia. Jeśli chcesz to zrobić z użytkownikiem lokalnym, wystarczy mieć plik blokady. Po uruchomieniu zatwierdzenia uzyskaj blokadę pliku. Po zakończeniu zatwierdzenia zwolnij blokadę. Jeśli chcesz zezwolić na zatwierdzanie wielu gałęzi jednocześnie, użyj pliku blokady dla każdej gałęzi. Jasne, SQLite zrobiłby to za mnie, ale nie jest to konieczne .
Przywróć Monikę
1
Podobnie wdrożenie podstawowego dziennika nie jest skomplikowane. (1) Zapisz nowy zatwierdzenie do pliku. (2) Skopiuj stary plik indeksu. (3) Napisz nowy plik indeksu. (4) Usuń kopię starego pliku indeksu. Jeśli nie uda Ci się wykonać kroku 1, 2 lub 4, musisz po prostu wyczyścić nowo utworzone pliki. Jeśli nie powiedzie się krok 3, wystarczy skopiować stary plik indeksu z powrotem. Ktoś, kto lepiej rozumie systemy plików, może prawdopodobnie stworzyć znacznie bardziej wydajną wersję tego pliku, ale zawsze możesz odwoływać się do kodu źródłowego SQLite, jeśli jest to konieczne (jest to domena publiczna).
Przywróć Monikę
1
@BrendanLong Świetne punkty. Doceń dyskusję. Żeby było jasne, uważam, że oba rodzaje sklepów z zapleczem mają zalety i wady, nie sądzę, aby była tylko jedna poprawna odpowiedź. Jednak byłem nieco zaskoczony, że wydaje się, że tylko trzy (cztery, jeśli liczyć Vault i Vercity osobno), które używają SQL, a zdecydowana większość nie, to wszystko.
Andy,
18

Właściwie svnużywany do używania BDB do repozytoriów. W końcu się go pozbył, ponieważ był podatny na pękanie.

Innym VCS, który obecnie korzysta z DB (SQLite), jest fossil. Zawiera także narzędzie do śledzenia błędów.

Domyślam się, że prawdziwy powód jest taki, że VCSes działają z wieloma plikami. Systemy plików to po prostu inny rodzaj bazy danych (hierarchiczny, skoncentrowany na wydajności pamięci CLOB / BLOB). Normalne bazy danych nie radzą sobie tak dobrze, ponieważ nie ma powodu - systemy plików już istnieją.

Mike Larsen
źródło
1
BDB nie byłby w pełni wiarygodny - podobnie jak SQLite to baza danych w trakcie przetwarzania. To powiedziawszy, uważam, że niezawodność Oracle / MSSQL / MySQL / Postgres, w zależności od tego, jak je konfigurujesz, niewiele różni się od systemów plików. Głównym problemem jest to, że RDBMS nie są budowane dla struktur hierarchicznych i graficznych, z którymi zwykle współpracują VCS. W takim przypadku systemy plików po prostu wygrywają.
Mike Larsen,
3
@Andy: Fossil został stworzony przez twórcę SQLite. Nie jest to aż tak zaskakujące :-)
Jörg W Mittag
1
@Andy: zaufałbym SQLite znacznie bardziej niż Oracle lub MSSQL. Nic dziwnego, że jest to najczęściej używana baza danych SQL. Ponadto jest to port przeniesiony do większości różnych architektur, z których każda ma własny zestaw wyzwań, dzięki czemu wspólny kod jest niewiarygodnie kuloodporny.
Javier,
1
@Javier Nie ufałbym Sqlite tak bardzo jak MSSQL lub Oracle; jak powiedział Mike, część procesu mnie przeraża, tak jakby twoja aplikacja umarła, co może teraz spowodować uszkodzenie bazy danych. W przypadku bazy danych klient / serwer umierający klient przerywa transakcję. Nie można powiedzieć, że nie jest możliwe uszkodzenie baz danych CS, ale sądzę, że jest to mniej prawdopodobne niż połączenie silnika DB z aplikacją.
Andy,
5
@Andy, po to są transakcje. Bez względu na to, w którym momencie zabijesz dobry silnik DB, dana transakcja zostanie zatwierdzona lub nie. Implementacja atomowych commits w SQLite ( sqlite.org/atomiccommit.html ) jest szczególnie skomplikowana.
Javier
10

  1. System plików to baza danych. Oczywiście nie jest to relacyjna baza danych, ale większość z nich to bardzo wydajne magazyny kluczy / wartości. A jeśli twoje wzorce dostępu są dobrze zaprojektowane dla magazynu klucz-wartość (np. Format repozytorium git), to użycie bazy danych prawdopodobnie nie oferuje znaczących korzyści w porównaniu z użyciem systemu plików. (W rzeczywistości jest to kolejna warstwa abstrakcji, która może przeszkadzać.)

  2. Wiele funkcji bazy danych to tylko dodatkowy bagaż. Wyszukiwanie pełnotekstowe? Czy wyszukiwanie pełnotekstowe ma sens w przypadku kodu źródłowego? A może musisz to inaczej tokenizować? Wymaga to również przechowywania pełnych plików przy każdej wersji, co jest rzadkie. Wiele systemów kontroli wersji przechowuje delty między wersjami tego samego pliku w celu zaoszczędzenia miejsca, na przykład Subversion i Git (przynajmniej przy użyciu plików paczek).

  3. Wymagania dotyczące wielu platform sprawiają, że korzystanie z bazy danych jest trudniejsze.

    Większość narzędzi kontroli wersji jest zbudowanych do działania na wielu platformach. W przypadku scentralizowanych narzędzi kontroli wersji wpływa to tylko na komponent serwera, ale nadal trudno jest polegać na jednym serwerze bazy danych, ponieważ użytkownicy systemu Unix nie mogą zainstalować Microsoft SQL Server, a użytkownicy systemu Windows mogą nie chcieć instalować PostgreSQL lub MySQL. System plików jest najmniej powszechnym mianownikiem. Istnieje jednak kilka narzędzi, w których serwer musi być zainstalowany na komputerze z systemem Windows, a zatem wymaga programu SQL Server, na przykład SourceGear Vault i Microsoft Team Foundation Server .

    Rozproszone systemy kontroli wersji jeszcze bardziej utrudniają, ponieważ każdy użytkownik otrzymuje kopię repozytorium. Oznacza to, że każdy użytkownik potrzebuje bazy danych do umieszczenia repozytorium. Oznacza to, że oprogramowanie:

    1. Jest ograniczony do podzbioru platform, na których istnieje określona baza danych
    2. Celuje w jeden backend bazy danych, który jest wieloplatformowy (np. SQLite).
    3. Celuje w backend pamięci wtykowej, aby można było korzystać z dowolnej bazy danych, którą chcieli (w tym także z systemu plików).

    Dlatego większość rozproszonych systemów kontroli wersji używa tylko systemu plików. Godnym uwagi wyjątkiem jest Veracity SourceGear , które może przechowywać w bazie danych SQLite (przydatne dla lokalnych repozytoriów) lub relacyjnej bazy danych, takiej jak SQL Server (być może przydatne dla serwera). Oferowana przez nich usługa w chmurze może wykorzystywać nierelacyjny backend pamięci, taki jak Amazon SimpleDB , ale nie wiem, czy to prawda.

Edward Thomson
źródło
Być może, podobnie jak komentarz adwokata diabła, większość osób, które zadają tego rodzaju pytania „dlaczego nie korzystać z bazy danych”, wydają się oznaczać „dlaczego nie korzystać z RDBMS?” z całą zgodnością ACID i innymi problemami. Fakt, że wszystkie systemy plików są już własnymi bazami danych, które zostały już odrzucone.
mikebabcock
6

O ile widziałem w wielu ofertach, wydaje się, że pliki są „wystarczająco dobre” do zadania, co jest rozsądne, biorąc pod uwagę, że pod koniec dnia wyjściem VCSes są również pliki.

Istnieje wiele firm, które oferują zaplecze RDBMS z interfejsem svn / git / etc, więc to, o co prosisz, już istnieje.

Dimitrios Mistriotis
źródło
5

Powiedziałbym, że dzieje się tak, ponieważ podstawową strukturą danych systemu kontroli wersji jest DAG, która bardzo słabo odwzorowuje bazy danych. Wiele danych jest również adresowalnych pod względem zawartości, co również bardzo słabo odwzorowuje bazy danych.

Integralność danych nie jest jedyną kwestią związaną z VCS, dotyczą one również integralności historii wersji , w których bazy danych nie są zbyt dobre. Innymi słowy, kiedy pobierasz wersję, musisz nie tylko upewnić się, że wersja nie ma aktualnych wad, ale także, że nic w całej historii nie zostało ukradkowo zmienione.

VCS są również produktem konsumenckim oprócz produktu korporacyjnego. Ludzie używają ich w małych, jednoosobowych projektach hobbystycznych. Jeśli dodasz kłopot związany z instalacją i konfiguracją serwera bazy danych, zrazisz większość tej części rynku. Domyślam się, że nie widzisz dużo instalacji Vault i TFS w domu. Z tego samego powodu arkusze kalkulacyjne i edytory tekstu nie korzystają z baz danych.

Jest to również powód DVCS, ale nieużywanie bazy danych czyni ją niezwykle przenośną. Mogę skopiować moje drzewo źródłowe na pendrive i użyć go ponownie na dowolnym komputerze, bez konieczności konfigurowania procesu serwera bazy danych.

Jeśli chodzi o zgorszenie podczas zatwierdzeń, VCS wykorzystuje te same techniki jak bazy danych, aby zapobiec jednoczesnego dostępu, transakcji, w atomowych itp zepsucie w obie są bardzo rzadkie, ale nie stało . Dla wszystkich celów i celów magazyn danych VCS jest bazą danych.

Karl Bielefeldt
źródło
1
„bardzo słabo odwzorowuje bazy danych” Jednak Vault i TFS właśnie to robią. „Integralność danych nie jest jedyną kwestią związaną z VCS, dotyczą one również integralności historii wersji, w których bazach danych nie są zbyt dobre”. Nie widzę, jak przechowywanie historii wersji nadaje się do plików w bazie danych, zwłaszcza, że ​​nazwałem produkty, które właśnie to robią. „. Korupcje w obu przypadkach są bardzo rzadkie, ale zdarzają się”. Żaden z tych wyników na pierwszej stronie nie mówi o uszkodzeniu bazy danych serwera Vault. Jedynym linkiem, który mówi nawet o oprogramowaniu Vault, jest problem, że toaleta została uszkodzona.
Andy,
„Pod każdym względem magazyn danych VCS jest bazą danych”. Cóż ... o to mi chodzi. Dlaczego nie po prostu umieścić danych w prawdziwym systemie baz danych zamiast tworzyć własne?
Andy,
2
@Andy Tak, to baza danych, ale nie wszystkie bazy danych są wzajemnie zastępowalne. Każda baza danych ma określony widok na świat (na przykład bazy danych SQL w zasadzie implementują model relacyjny). Jak podaje ta odpowiedź, dane przechowywane przez VCS i sposób ich wykorzystania nie pasują do modelu relacyjnego. Nie jestem pewien, czy niektóre bazy danych NoSQL radzą sobie lepiej, ale są one raczej nowe i jeszcze nie udowodniły swojej wyższości (niektórym przypominam raporty o poważnych problemach z integralnością). A poza tym są jeszcze inne problemy.
DAG są używane tylko w DVCS (chyba że uważasz historię liniową za wyjątkowo prostą DAG, ale tak naprawdę nie jest to pomocna abstrakcja). Kiedy twoja historia jest liniowa, z monotonicznie rosnącymi zestawami zmian, baza danych SQL ma o wiele większy sens .
Edward Thomson,
Monotonicznie rosnące numery wersji nie mają większego sensu dla VCSes. Użyłem ich całkiem sporo, a te ze scentralizowanymi numerami wersji (CVS i SVN to 2, które znam najbardziej) są zwykle trudnym połączeniem. I nawet ci używają DAG, kiedy próbują połączyć. To, że ich reprezentacja pamięci nie jest oparta, nie oznacza, że ​​nie jest używana.
Mike Larsen,
2

  • Lepsze odzyskiwanie po awarii (najgorszy scenariusz: przeanalizujemy to naocznie, jak w dawnych czasach)

  • Ułatwienie śledzenia i debugowania takich katastrof, prawdopodobnie spowodowanych błędami w systemie VCS.

  • Obniżenie liczby zależności. (nie zapominajmy o jednym z tych systemów jest obchodzenia się z jądra, a drugi miał)

  • Edytor tekstu jest zawsze dostępny. (Licencje MS SQL Server ... nie bardzo)

ZJR
źródło
Ta odpowiedź jest po prostu zła. Jedynym prawdziwym punktem jest obniżenie liczby zależności. Oba systemy tworzenia kopii zapasowych powinny być na równi, ponieważ powinieneś wykonywać odpowiednie kopie zapasowe, debugowanie aplikacji DB nie jest trudniejsze niż debugowanie aplikacji, które zapisują pliki, a edytor tekstu jest zawsze dostępny? Nie wiem nawet o co ci chodzi, ponieważ VCS sam nie zamierza używać edytora tekstu, a istnieją jeszcze inne serwery DB (Sqlite, Postgre, MySql itp.), Więc jeśli CHCESZ rozwiązanie oparte na db brak serwera db nie powinien być czynnikiem.
Andy,
1
@Andy ... programiści użyją edytora tekstu. Wiesz, edycja tekstu jest nadal dostępna jako dodatkowa funkcja, nawet w twoim ulubionym IDE.
ZJR
1
@Andy sqlitejest jedyną możliwą alternatywą dla plików tekstowych, biorąc pod uwagę ogromną liczbę rozproszonych scenariuszy, które obsługują nowoczesne DVCS. (idk, być może przegapiłeś „rozproszoną” część DVCS) Wszystko inne byłoby zbyt kłopotliwe (konfiguracja + zapora ogniowa + licencja) lub nawet głupie, aby je rozpowszechnić . Z drugiej strony wykonanie najgorszego scenariusza po śmierci na sqlite może okazać się trudne.
ZJR
1
@ZJR: Nie sądzę, oryginalne pytanie kiedykolwiek podano rozproszonego systemu kontroli wersji, to poprosił o systemach kontroli wersji w ogóle. Ponadto argument edytora tekstu jest nieco płaski, ponieważ wiele systemów nie przechowuje tylko płaskich plików tekstowych. Nawet git ma wiele formatów plików binarnych (luźne obiekty, pliki paczek itp.), Które czynią twój edytor tekstu bezużytecznym.
Edward Thomson,
@ZJR W jaki sposób edycja kodu w edytorze tekstów trafia do magazynu kopii zapasowych VCS? Czy sugerujesz ręczną edycję, powiedzmy, baza danych SVN? Również moje pytanie nie ogranicza się do DVCS, więc nie wiem, dlaczego się na to skupiasz.
Andy,
2

Fossil to doskonały rozproszony system kontroli wersji (DVCS), który używa SQLite do przechowywania danych, bez plików tekstowych.

Naprawdę podoba mi się, że ma zintegrowane: śledzenie błędów, Wiki i to, że jest naprawdę rozproszone. Mam na myśli, że naprawdę możesz pracować w trybie offline i naprawiać błędy.

Fossil używa Sqlite jako formatu pliku aplikacji. W przemówieniu PgCon dr Richard Hipp wyjaśnia, jakie są zalety korzystania z sqlite jako systemu plików aplikacji, i dość przekonująco argumentuje na korzyść korzystania z bazy danych jako systemu plików.

Drugim głównym tematem było to, że SQLite powinien być postrzegany jako format pliku aplikacji - alternatywa dla wymyślania własnych formatów plików lub korzystania ze skompresowanych plików XML. Oświadczenie „SQLite nie zastępuje PostgreSQL. SQLite jest zamiennikiem gwoździ fopen () ”, które (slajd 21). Wreszcie Richard położył duży nacisk na fakt, że SQLite dba o twoje dane (bezpieczne w razie awarii, ACID) use-the-index.com

Teraz dr Hipp zajął się obawami dotyczącymi zapisywania kodu w bazie danych

  • Dlaczego Fossil oparty jest na SQLite zamiast rozproszonej bazy danych NoSQL?

Skamielina nie jest oparta na SQLite. Obecna implementacja Fossil wykorzystuje SQLite jako lokalny magazyn zawartości rozproszonej bazy danych oraz jako pamięć podręczną dla meta-informacji o rozproszonej bazie danych, które są wstępnie obliczane w celu szybkiej i łatwej prezentacji. Jednak użycie SQLite w tej roli jest szczegółem implementacyjnym i nie jest fundamentalne dla projektu. Niektóre przyszłe wersje Fossil mogą pozbyć się SQLite i zastąpić stos plików lub bazę danych kluczy / wartości zamiast SQLite. (W rzeczywistości jest to bardzo mało prawdopodobne, ponieważ SQLite działa niesamowicie dobrze w swojej obecnej roli, ale chodzi o to, że pominięcie SQLite w Fossil jest teoretyczną możliwością.)

elviejo79
źródło