Plusy i minusy za przechowywanie kodu i danych w oddzielnych repozytoriach

Question

Mamy projekt, który zawiera dane i kod, w pakiecie w jednym repozytorium Mercurial. Dane są tak samo ważne jak kod (zawiera parametry logiki biznesowej, niektóre dane wejściowe itp.) Jednak format plików danych rzadko się zmienia i naturalnie jest zmieniać pliki danych niezależnie od kodu.

Jedną z zalet zunifikowanego repozytorium jest to, że nie musimy śledzić wielu wersji: jeśli kiedykolwiek zajdzie potrzeba odtworzenia danych wyjściowych z poprzedniego uruchomienia, wystarczy zaktualizować system do pojedynczego numeru wersji przechowywanego w dziennik wyjściowy.

Jedną wadą jest to, że jeśli zmodyfikujemy dane, gdy wiele głowic jest aktywnych, możemy utracić zmiany danych, chyba że ręcznie skopiujemy te zmiany do każdej głowicy.

Czy są jeszcze jakieś plusy/minusy dzielenia kodu i danych na osobne repozytoria?

Answer 1

Wiele repo:

• pros:

  • component-based approach (w identyfikacji grup plików, który może ewoluować niezależnie jeden od drugiego)
  • specyfikację konfiguracji: Ci listę referencji (tutaj "rewizje"), których potrzebujesz r system do pracy. Jeśli chcesz zmodyfikować jedną część bez zmiany drugiej, zaktualizujesz tę listę.
  • częściowe klony: jeśli nie trzeba wszystkie elementy można klonować tylko te, które chcesz (nie ma zastosowania w danym przypadku)

• minusy

  • zarządzania konfiguracją : musisz śledzić tę konfigurację (zazwyczaj poprzez nadrzędne repozytorium, rejestrowanie subrepos)
  • w twoim przypadku dane są całkowicie zależne od niektórych wersji projektów (możesz mieć nowe dane, które nie mają sensu dla starych wersji Jony projektu)

---

Jeden repo

• plusy
  • system-based approach: widzisz swoje moduły w jednym systemie (projektu i danych).zarządzanie
  • repo: wszystko w jednym
  • szczelne połączenie między modułami (które może sens dla danych)
• minusy
  • propagacji danych (kiedy, jak wspomina, kilka głowie są aktywne)
  • korekty pośrednie (aby nie odzwierciedlać nowej funkcji, ale tylko dlatego, że niektóre zmiany danych)
  • większy klon (nie dotyczy tutaj, chyba że dane są duże pliki binarne)

dla danych binarnych bez zmian, z rzadka, chciałbym jeszcze utrzymać je w tym samym repo.

Answer 2

Tak, należy oddzielić kod i dane. Zachowaj kod w kontroli wersji i swoje dane w bazie danych.

Uwielbiam kontrolę wersji, ponieważ jestem programistą od ponad dziesięciu lat i lubię tę pracę.

Ale w ciągu ostatnich miesięcy zrozumiałem: Dane nie mogą mieć kontroli wersji. Czasami trudno jest osobie, która jest obeznana z git (lub innym systemem kontroli wersji), aby "odpuścił".

Potrzebujesz dobrej organizacji ORM obsługującej migracje schematu bazy danych. Migracje (schemamigracje i datamigracje) są utrzymywane w kontroli wersji, ale dane nie są.

Wiem, że twoje pytanie dotyczyło użycia jednego lub dwóch repozytoriów, ale może moja odpowiedź pomoże Ci uzyskać inny punkt widzenia.