Aktywne Wpisy
mirabelka2137 +376
BlackBlack +201
Podsumowując:
1. Jedź pod wpływem alkoholu
2. Uderz w motocyklistę
3. Ucieknij z miejsca zdarzenia (bo nawet nie zauważyłeś, że jesteś sprawcą kolizji
4. Motocyklista podnosi się i Cię dogania mówiąc, żebyś się zatrzymał i wszystko ma nagrane
5. Znowu uciekasz
6. Sprawa trafia do sądu i dostajesz karę
7. Trzyletni zakaz prowadzenia pojazdów mechanicznych i 12k grzywny
8. Nazywasz się Jerzy Stuhr
Zawsze mnie wkurzają niewielkie kary dla gwiazdorów-przestępców. Uważam, że
1. Jedź pod wpływem alkoholu
2. Uderz w motocyklistę
3. Ucieknij z miejsca zdarzenia (bo nawet nie zauważyłeś, że jesteś sprawcą kolizji
4. Motocyklista podnosi się i Cię dogania mówiąc, żebyś się zatrzymał i wszystko ma nagrane
5. Znowu uciekasz
6. Sprawa trafia do sądu i dostajesz karę
7. Trzyletni zakaz prowadzenia pojazdów mechanicznych i 12k grzywny
8. Nazywasz się Jerzy Stuhr
Zawsze mnie wkurzają niewielkie kary dla gwiazdorów-przestępców. Uważam, że
Aktywne Znaleziska
TL; DR
Bywają duże projekty, ale dla uproszczenia weźmy kernel - ok 100k plików i 3GiB miejsca. Powiedzmy że macie X starych projektów, gdzie po pewnym czasie - nawet gdyby ktoś chciał - nie sposób trzymać zmian w postaci łatki. Strata miejsca i i-węzłów na trzymaniu X kopii, przeszukiwanie dysku jest wolniejsze.
Przyszło mi do głowy by trzymać sobie takie projekty w kontenerze. Czyli tworzę sobie projekt.img, formatuję jako btrfs, montuję i volia. Dla dodatkowej oszczędności można by jeszcze projekt.img trzymać jako sparse. Łatwo i szybko można taki projekt otworzyć (w stosunku do trzymania go w jakimś zipie), można go po zamontowaniu zaktualizować jeśli potrzeba. Jedyne co, to nawet przy niewielkiej zmianie można oczekiwać że X GB kontener będzie trzeba synchronizować z backupem w dużej części. Gdyby to było archiwum tar, to ok, niewielka zmiana w "zamontowanym" archiwum zmieni tylko niewielki kawałek kontenera.
Zastanawiam się czy ktoś rozważał kiedyś podobną kwestę i na co się zdecydował. W przypadku gdy projekt już nigdy nie będzie aktualizowany to sprawa wydaje się w miarę prosta - rozważasz tylko kompromis między siłą kompresji i czasem jaki chcesz czekać na rozpakowanie. Jaka jest twoja ulubiona forma przypadku częstych aktualizacji? Usuwasz katalog roboczy zostawiając tylko ".git"? Wrzucasz do paczki swojego ulubionego formatu pakującego? Czy w ogóle bajzel, wszystko jedno i leży katalog z plikami i tyle ;)
#programowanie
git filter-repo, żeby usunąć śmieci z starych commitów (głównie binarki i skompresowane pliki). Jeśli nie chcesz trzymać całej historii na dysku to robisz używasz sztuczek używanych w monorepo: spare checkout i shallow cloneIdąc dalej - nie wiem czy pracowałeś nad dużymi projektami - ale podejrzewam że wiesz, że w zasadzie często - 1 projekt to niejedno repo. Można się bawić w repo manifesty jak android, czy
@Oo-oO: przecież masz prywatne repa. Zresztą chyba nie powiesz mi, że istnieje pracodawca, którego życzeniem jest trzymanie swojego cennego kodu na czyimś laptopie ( ͡° ʖ̯ ͡°)
No moim zdaniem porządkuje jak najbardziej. Po pierwsze przyjmijmy sobie założenie że ktoś z jakiejś przyczyny pracował w dwóch projektach androida, i trzyma je na dysku. Mógłby oczywiście używać jednego repo
git gc --aggressivemam 1.8GB. Nawet jak będę pracował nad 10 repo w skali linuxa (co wydaje mi się nieprawdopodobne) to czym jest 20GB w dzisiejszych czasach?