[WewnetrznySpokoj]

Pracuję nad prywatnym mini systemem do zarządzania projektami. Każdy projekt zawiera różne pliki (graficzne, tekstowe itd.), których struktura często się zmienia. Chciałbym w ramach systemu stworzyć prosty system kontroli wersji - użytkownik modyfikuje lokalne pliki, robi commit, system po checksumach sprawdza które pliki się zmieniły i tak dalej. Widzę dwie opcje zapisywania tych plików:

1. W jednym wielkim folderze. Pliki byłyby nazywane uuidami, a w bazie trzymałbym ich właściwe nazwy i checksumy.

2. Osobny folder do każdego projektu, w środku osobny folder dla każdego commita, w środku folderów zmodyfikowane pliki z oryginalnymi nazwami.

Który sposób byłby waszym zdaniem lepszy? Z jednej strony 2 wydaje się być bardziej uporządkowany tak na Chłopski Rozum® (i pozwalałby na łopatologiczny debugging jeśli zaszłaby taka potrzeba), z drugiej strony nadaję danym pół-oficjalną strukturę, którą później ciężko byłoby zmienić (jeśli zaszłaby taka potrzeba). 1 byłby prosty do np. przeniesienia na jakiś object storage i wydaje się bardziej uporządkowany od strony programistycznej.

Czy folder z, powiedzmy, 20.000 plików mógłby stwarzać w przyszłości jakieś problemy?

#programowanie #backend #nodejs #programista15k

[Saly]

@WewnetrznySpokoj: czemu nie użyc po prostu gita?

[n.....e]

@Saly: mi to wyglada na jakis projekt to nauki :d

[Saly]

@nietrolluje: warto byłoby to napisać, bo to zmienia wszystko xd

[WewnetrznySpokoj]

@Saly: @nietrolluje: Nie do nauki, ale ogólnie dopiero zaczynam poważniej ogarniać backend, więc w sumie do nauki też. Ale projekt jest na serio, potrzebuję czegoś takiego. Git byłby w mojej ocenie zbędną komplikacją, bo ten element kontroli wersji ma być podstawowy i dorzucony przy okazji. Możecie wykreślić część o kontroli wersji i zostawić tylko pytanie o zarządzanie plikami należącymi do różnych projektów - wielki folder czy podział na projekty?

[Saly]

1. W jednym wielkim folderze. Pliki byłyby nazywane uuidami, a w bazie trzymałbym ich właściwe nazwy i checksumy.

@WewnetrznySpokoj: po co dwie bazy do tego samego (system plików i wspomniana baza) skoro można użyć jednej?

[n.....e]

@WewnetrznySpokoj: git albo perforce jesli masz duzo plikow wlasnie binarnych/zdjec itp, jesli sie struktura zmienia to powinien wykryc 'move'.
Zalezy czy ludzie maja miec mozliwosc np. "zablokowania" innym mozliwosci pracy nad danym plikiem. Jesli tak to potrzebujesz scentralizowanego rozwiazania jak p4.

Jesli nie ma az takich wymagan to moze cos S3 podobnego albo faktyczna chmura albo np. minio https://min.io/
Zaleta minio jest to, ze jest S3 compatible wiec przeskok na chmure

[zibizz1]

@WewnetrznySpokoj: To czy folder per projekt czy nie to zależy czy pliki mogą przechodzić pomiędzy projektami? Jeśli nie to robiłbym per projekt

@Saly: Jak trafi się plik 20MB to baza też łyknie?

[Saly]

Git byłby w mojej ocenie zbędną komplikacją, bo ten element kontroli wersji ma być podstawowy i dorzucony przy okazji. Możecie wykreślić część o kontroli wersji i zostawić tylko pytanie o zarządzanie plikami należącymi do różnych projektów - wielki folder czy podział na projekty?

@WewnetrznySpokoj: jak uważasz, dla mnie git jest na tyle prosty i uniwersalny, że klepanie czegoś takiego samemu to tylko proszenie się o kłopoty. Jeśli chodzi o strukturę to

[zibizz1]

@WewnetrznySpokoj: A i ja bym zył gotowego rozwiązania do synchronizacji plików, albo jakiś owncloud, albo prefroce jeśli duzo binarnych plików

[n.....e]

jak uważasz, dla mnie git jest na tyle prosty i uniwersalny, że klepanie czegoś takiego samemu to tylko proszenie się o kłopoty.

@Saly: dokladnie, to sie tak "wydaje" tylko, ze "e tam", to sie zateguje do pierwszego powaznego edgecase, ktory wywraca ci architekture i czas stracony ( ͡° ͜ʖ ͡°) A, ze to wlasne, customowe to 0 pomocy.
Git, P4, TFS to mozna chociaz googlowac.

[WewnetrznySpokoj]

po co dwie bazy do tego samego (system plików i wspomniana baza) skoro można użyć jednej?

@Saly: Bardzo dużo bardzo dużych plików, w sumie ponad 3TB, niektóre pojedyncze do 10GB. Z tego co się zorientowałem to lepiej takich rzeczy nie pakować do DB skoro można je trzymać w filesystemie i wyciągać po nazwie.

[n.....e]

@WewnetrznySpokoj: Ło panie

Perforce.

[WewnetrznySpokoj]

@nietrolluje: Wszystko spoko tylko ja w devopsowych rzeczach jestem zielony, zanim to wszystko poogarniam to już bym (wedłiug oryginalnego pomysłu) 4 razy całość od zera napisał (╯︵╰,)

[WewnetrznySpokoj]

@nietrolluje: Cała sprawa polega na tym, że w projektach występuje kilka customowych rodzajów plików, do których mam napisane customowe edytory, chcę mieć po prostu jedną appkę do przeglądania i edytowania tych plików z ładnym GUI. Do tego dochodzą inne integracje, pliki z projektów w różnych sytuacjach lecą w różne miejsca przez różne API. Stąd w ogóle idea tworzenia własnego systemu zarządzania projektami, bo mógłbym to wszystko zintegrować. A zarządzanie wersjami to

[Henryhenry]

@WewnetrznySpokoj: nikt w wątku nie wspomniał, że w przypadku repozytorium z dużymi plikami (binarnymi najczęściej) git potrzebuje git-lfs

[draxgar]

@WewnetrznySpokoj: duże ilości plików w jednym katalogu spowoduje problemy. Wejdziesz do takiego katalogu, ale już nie wylistujesz plików. Duże ilości to >50k czy 100k. Także dlatego git tworzy katalogi, które są pierwszymi znakami sha.

[scripter001]

@WewnetrznySpokoj: Cześć, chciałem napisać priv, ale masz jednak zablokowane. Byłbym wdzięczny za feedback