1. Dom
  2. Pytanie i odpowiedź
  3. Czy Git jest zalecany dla dużych repozytoriów treści (> 250 GB)?

Czy Git jest zalecany dla dużych repozytoriów treści (> 250 GB)?

2009-06-16 4 views
27

Aplikacja internetowa to specjalnie zbudowany CMS, który ma kilka pod-aplikacji, a każdy z nich ma kod i treść znajdującą się w tej samej strukturze katalogów. Ze względu na architekturę szkieletu aplikacji kod i treść są ze sobą powiązane (treść zależy od kodu wyświetlania i innych funkcji), a zatem są nierozłączne. Treść nie jest przechowywana jako BLOB, a raczej jest przechowywana jako pliki, a bazowy DB służy do ich łączenia. Rozmiar pod-aplikacji waha się od 20 GB - 250 GB i więcej (to jest zabójca).Czy Git jest zalecany dla dużych repozytoriów treści (> 250 GB)?

Aplikacja internetowa będzie zawierała pewne ulepszenia w kodzie (nowe podaplikacje, poprawki błędów itp.), A jednocześnie użytkownicy dodadzą/zaktualizują zawartość za pomocą już istniejącego systemu. W związku z tym wymagany jest proces wdrożenia/wydania, a co najważniejsze, system sterowania wersjami musi zostać zasugerowany zarówno w odniesieniu do kodu, jak i treści.

Git przychodzi do obrazu z powodów - jest to open source & wolny, łatwość rozgałęzienia & scalanie, jego awaria nie scentralizowana jednopunktowy-of-& stąd nie ma.

ALE po kilku wstępnych badaniach w sieci, odkryłem pewne rozczarowujące fakty, które odnoszą się do naszej aplikacji - używanie Git w dużych systemach takich jak nasz jest bolesne (kasowanie, klonowanie, scalanie, pchanie, ciągnięcie) i polecenia są skomplikowane ("geeky" byłoby bardziej odpowiednie) dla bazy programistów, którzy są ignorantami DVCS, a przede wszystkim użytkownicy systemu Windows.

Nie ma ustalonego sposobu myślenia dla Git, ale jeśli muszę zastosować podejście scentralizowane (w naprawdę WORST przypadku), to jaka powinna być droga (CVS & SVN od siebie). Czytałem o tym, że Perforce jest stabilny i jest również używany w Google (spodziewam się tutaj trochę spięć !!).

Udostępnij, prowadź i komentuj swoje opinie. Naprawdę ich potrzebuję.

Źródło

2009-06-16 kaychaks

+7

Git nie został zaprojektowany dla tak dużych repozytoriów (chociaż prace nad poprawą zachowania dużych plików i dużych repozytoriów są w toku) ... ale myślę, że miałbyś problemy z wydajnością jakichkolwiek systemów kontroli wersji, które nie działają. wykonywać operacje na drodze (które ma swoje poważne wady) lub nie obsługuje częściowych kas. Czy naprawdę potrzebujesz do kontroli wersji tych dużych plików razem z kodem? –

+0

Właśnie przeczytałem o DVCS zwanym [monotone] (http://www.monotone.ca). Może być dla ciebie alternatywą. –

+0

Mam obecnie do czynienia z ogromnym repozytorium. Badam submoduły, aby sprawdzić, czy to w ogóle poprawia. –

Odpowiedz

24

Po prostu zdarzyło mi się czytać this blog post minutę temu. To trochę rant o skalowalności gita.

Edycja: Osiem lat później, a Git ma Large File Storage (LFS), a firma Microsoft jest open source pozyskiwania Git Virtual File System (GVFS), dzięki czemu mogą używać git do rozwijania systemu Windows.

Źródło

2009-06-16 06:12:12 pgs

+0

Nice post :) Hmm, czy są to problemy, które można rozwiązać, a może to projekt git, który jest w błędzie? –

+0

Rozwiązanie? Nie wiem Linus zaprojektował git do obsługi drzewa kodu źródłowego Linuksa, co bardzo dobrze wykonuje. Ale to prawie wszystkie pliki tekstowe. Repozytorium, kasy i zbudowane obiekty mają łącznie mniej niż 2 GB na moim komputerze. – pgs

+4

Link prawdopodobnie przeniesiono tutaj: http://stevehanov.ca/blog/index.php?id=50 – krubo

-2

Użyłem git tylko raz do projektu szkolnego (strona php z Zend Framework).

Użyliśmy gita, ale nauczyciel musiał mieć ostateczne wydanie na repozytorium svn.

Porównując wielkość Checkout:

git checkout był o połowę mniejszy od MB kasie svn.

Moje dwa centy.

Źródło

2009-06-16 05:51:06 Macarse

+1

Oczywiście, i zawsze będzie, ponieważ SVN przechowuje kopię BASE wewnątrz kopii roboczej (w folderze .svn). Oznacza to, że różnice, powrót, itp. Nie wymagają sieci. SVN został stworzony do obsługi komunikatorów o niskiej przepustowości (myślę, że dialup). – si618

+5

git utrzymuje także różnice - jest to system kontroli wersji rozproszonej, więc nie potrzebujesz sieci, aby móc pracować – stefanB

+3

Stefan ma rację.SVN będzie/nie/pozwala na wykonywanie dowolnych różnic, a jedynie różnicę w stosunku do najnowszej aktualizacji. Jeśli chcesz pracować w trybie offline, potrzebujesz prawdziwego DCVS, którego SVN nie jest. –

16

Po pierwsze, nie zgadzam się, że Git jest nieodpowiedni dla użytkowników nietechnicznych. Tak, istnieją pewne funkcje, których początkujący nie będą używać (np. Git-send-email). Ale są też GUI, takie jak TortoiseGit, aby proste rzeczy były proste.

Jednak myślę, że podchodzisz do rzeczy w niewłaściwy sposób. Zasadniczo masz treści, które będą się często zmieniać i muszą być edytowalne bardzo łatwo przez Joe Bloggs, a kod, który będzie modyfikowany rzadziej przez programistów. Tradycyjnym rozwiązaniem jest użycie prawdziwego CMS (np. Alfresco, SugarCRM, Drupal, itp. Lub Wiki (MediaWiki, MoinMon, itp.), Z opcjonalnymi wtyczkami. Pamiętaj, że wiki (i większość CMSów) umożliwia wersjonowanie treść, w sposób "przyjazny dla użytkownika"

Nawet jeśli musisz zachować swój wewnętrzny kod, myślę, że powinieneś chcieć wyekstrahować treść, aby można było traktować je osobno. oddzielne, twoje repozytorium będzie miało rozsądniejszy rozmiar, a następnie możesz użyć dowolnego VCS, którego potrzebujesz (chociaż nie jestem pewien, czy masz rację, że Git jest z natury zły dla dużych repozytoriów).

Źródło

2009-06-16 05:54:40

+4

Matthew, czy użyłeś TortoiseGit samemu? Nie, ale mam wrażenie, że nadal jest bardzo beta (jeśli nie alpha). Próbowałem też używać MSYS Git w Windowsie i uważam, że jest przyziemne i idiosynkratyczne. Bez użytecznego interfejsu GUI, takiego jak TortoiseGit, naprawdę nie nadaje się dla osób nietechnicznych lub osób o słabym sercu. – Evan

+0

Evan, nie miałem jeszcze okazji go użyć. Jest jednak oparty na popularnym TortoiseSVN i jest aktywnie utrzymywany. Dlatego zdecydowanie uważam, że jest użyteczny. –

+3

Eksperymentowałem z TortoiseGit bardzo krótko w moim miejscu pracy, ponieważ ocenialiśmy alternatywne systemy kontroli źródła. Moi nietechniczni użytkownicy testów byli kompletnie zdezorientowani i zdezorientowani, aw ciągu kilku godzin byli aktywnie wrogo nastawieni. – Crashworks

8

Czy SVN jest naprawdę tak złą opcją?

PROŚ:

  • może obsługiwać duże repozytorium np wiele distro linux wykorzystajmy go również Apache, Sourceforge
  • ma ładne GUI front-end z TortoiseSVN, aby utrzymać użytkowników Windows szczęśliwy
  • Może być używany z zintegrowane uwierzytelnianie systemu Windows, aby utrzymać adminów szczęśliwy
  • wielu różnych strategii tworzenia kopii zapasowych mogą być przyjęte w oparciu o Twoje wymagania (svnadmin hotcopy lub dump, svnsync, hooky po zatwierdzeniu), aby złagodzić obawy związane z pojedynczym punktem awarii.

Wady:

  • Scentralizowane VCS

Uwaga: nigdy nie używany z konieczności i być szczęśliwym SVN administratora i użytkownika do ~ 6 lat (od v0.29)

Źródło

2009-06-16 06:47:09 si618

+0

Myślę, że rozmiary plików, o których mówimy, spowodują problemy z każdym systemem - 250 GB plików w jednym kasie, bez względu na obciążenie VCS, będzie bolesne w sieci. –

+0

Zgadzam się z Seanem, ale jeśli chce on rozwiązania VCS, dlaczego wybrać system zaprojektowany dla kodu źródłowego, a nie dowolnego typu pliku? – si618

+0

+1 Dodatkowy con: nie tak dobry z połączeniami. SVN jest nadal bardzo dobrym narzędziem, a nie czymś, co powinno być po prostu odrzucane arbitralnie jako "nie warto". – jpmc26

10

git nie skaluje się dla dużych repozytoriów. To nie jest przestrzeń, to liczba plików. Proszę przeczytać mój blog article, który napisałem chwilę o tym.

Z mojego doświadczenia wynika, że ​​jeśli chcesz skalowalnego, szybkiego, scentralizowanego systemu kontroli kodu źródłowego, to jest droga do zrobienia.

Źródło

2009-06-17 21:37:27

+0

Perforce jest tak dobra w tym konkretnym przypadku. Pixar przechowuje każdą klatkę każdego filmu, który robi w Perforce. To dużo danych. Ten link jest trochę propagandy Perforce, ale nie możesz dyskutować z liczbami, które opisuje. Bardzo dobrze się skaluje. https://www.perforce.com/blog/140924/pixars-templar-big-data-asset-management-built-scale –

4

Istnieje skrypt narzędziowy o nazwie git-split, który powoduje zmianę repozytorium git, aby był bardziej wydajny.

Źródło

2009-11-19 17:03:28

 Powiązane problemy

  • Brak powiązanych problemów^_^