Autor Wątek: Poszukiwany: Dobry i darmowy program do backupu lokalnego  (Przeczytany 5286 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 11, 2014, 12:15:10
Cytuj
Tylko nie widzę sensu implementacji kompresji
Gigantyczna ilość małych plików zajeżdża file system - po prostu kopiuje się długo. A że coraz więcej moich projektów ma lokalnie własne gity, to tych małych plików się zbiera.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Xender

  • Użytkownik

# Grudzień 11, 2014, 22:07:42
Gigantyczna ilość małych plików zajeżdża file system - po prostu kopiuje się długo.
Kompresja jak najbardziej ma sens. Tylko implementowanie jej samemu nie.

A że coraz więcej moich projektów ma lokalnie własne gity, to tych małych plików się zbiera.
Git gc, chyba tą komendą da się przepakować całe repo, w instrukcji powinno być, jaka dokładnie opcja. Chyba, że nie ufasz Gitowi i chcesz najpierw backupować obiekty gita.

Tylko z nimi jest taki problem, że każdy z tych plików już jest skompresowany osobno, więc samym sklejeniem ich w jeden coś zyskasz, ale dalszą kompresją niespecjalnie.
Git jak w ramach gc pakuje luźne obiekty w packfile, to robi binarne delty między blobami (stosując heurystykę, że w 2 następnych commitach bloby, które są w tym samym miejscu w drzewie, pewnie będą różnić się tylko nieznacznie i delta wyjdzie mała).

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 12, 2014, 00:33:58
Cytuj
Kompresja jak najbardziej ma sens. Tylko implementowanie jej samemu nie.
W żadnym momencie nie miałem zamiaru implementować samemu kompresji.

Cytuj
Git gc, chyba tą komendą da się przepakować całe repo
Wielkie dzięki. Działa elegancko. :)

Cytuj
Tylko z nimi jest taki problem, że każdy z tych plików już jest skompresowany osobno, więc samym sklejeniem ich w jeden coś zyskasz, ale dalszą kompresją niespecjalnie.
I bardzo dobrze - inaczej słabo by to świadczyło o gicie.

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Grudzień 12, 2014, 01:34:56
jak dla mnie git spokojnie starcza, wiekszosc projektow trzymam na bitbucket a lokalnie te z ktorymi cos akurat robie takze zdziwily mnie te zawile wymagania :P

Offline ArekBal

  • Użytkownik

# Grudzień 12, 2014, 09:57:06
Trochę z innej beczki ale...Wiem, że prototypy robi się najlepiej w tym co się zna najlepiej. Ale powinieneś spróbować jakichś innych języków bo Java w szczególności to nie jest język do prototypowania. To jest takie ,,biznesowe C++'' -- do robienia heavy duty server side. Prototypuje się to w Javascriptcie, Pythonie czy innym Perlu. Generalnie do prototypów chcesz jak najwygodniejszego REPL-a/testowania i masy bibliotek (tak, Python, patrzę właśnie na ciebie!).
Śmiesznie że podsuwasz python-a akurat(jak rozumiem jako przykład dobrego "ob-lib-owienia"), któremu brak obecnie porządnej alternatywy dla Mavena, NuGeta, NPM.
Przykład z Javascript też jest chybiony ale z innego powodu, brak intellisense na porządnym poziomie powoduje słabe "API dicoverability" i literówki... spowalniające prototypowanie... każdy kto klecił jakiś większy przykład w JSFiddle to potwierdzi. Jakby zaprząc do tego TypeScript z definitely typed to może coś produktywnego(w dziedzinei prototypowania) by z tego wypłynęło.

Jaasne że tutaj się świat nie kończy, i ktoś kto na haskellu zęby zjadł, a inne rzeczy tylko pobieżnie zna... szybciej proto skleci w swoim języku. Ale ze względu na ogólnie rozumiane funkcjonalności, IDE, paczkowanie to nie widzę obecnie równego konkurenta... (o proto mowa!!!)
1. Java,
2. C#(z IDE trochę wyżej, PM trochę gorzej od Java),
3. JavaScript,
4. Python(ze względu na PTVS, a mimo braku udanego PM).

W temacie GIT nie będę wszczynał wojny, bo sam używam go do takich rzeczy właśnie, a repozytoria trzymam na VS Online. Ale to programistyczne śmieci. Jeśli kiedyś rzeczywiście zacznę zbierać kontent sam, albo będę musiał/mógł coś z chłopakami(dziewczynom nie ujmując) sklecić, to coś własnego na 100% z tego wyjdzie.
« Ostatnia zmiana: Grudzień 12, 2014, 10:06:22 wysłana przez ArekBal »

Offline Xion

  • Redaktor
    • xion.log

  • +3
# Grudzień 12, 2014, 11:44:00
Cytuj
Śmiesznie że podsuwasz python-a akurat(jak rozumiem jako przykład dobrego "ob-lib-owienia"), któremu brak obecnie porządnej alternatywy dla Mavena, NuGeta, NPM.

Offline bies

  • Użytkownik

# Grudzień 12, 2014, 19:00:42
(...)to nie widzę(...)
O to mi chodziło, może warto się rozejrzeć.

Offline Xender

  • Użytkownik

# Grudzień 12, 2014, 23:15:35
Śmiesznie że podsuwasz python-a akurat(jak rozumiem jako przykład dobrego "ob-lib-owienia"), któremu brak obecnie porządnej alternatywy dla Mavena,
LOL config w XML
LOL "chciałbym build system do języka interpretowanego"

NuGeta, NPM.
O PiP nie słyszał?

Ale ze względu na ogólnie rozumiane funkcjonalności, IDE, paczkowanie to nie widzę obecnie równego konkurenta... (o proto mowa!!!)
Jakie proto? To?
https://en.wikipedia.org/wiki/Proto_%28tools%29

1. Java,
2. C#(z IDE trochę wyżej, PM trochę gorzej od Java),
3. JavaScript,
4. Python(ze względu na PTVS, a mimo braku udanego PM).
Języki kompilowane do prototypowania...
Gorzej, używanie IDE do prototypowania...

> Mam fajny pomysł! Zakodzę.
> Odpalanie IDE...
> Ekran ładowania...
> Pójdę po herbatę, to się załaduje...
> Otworzył się projekt, nad którym siedziałem poprzednio.
> Dobra, robimy nowy projekt.
> Kilk-klik
> Podaj nazwę nowego projektu.
> Klik-klik next->next->next.
> Gotowe, można kodzić.
> Eee, co ja właściwie chciałem pisać?
> [kodzenie]
> Dobra, wypadałoby to zrefaktoryzować.
> "Kreator tworzenia nowej klasy" o_O (hej, chciałem tylko dodać plik do projektu).
> Klik nazwa klasy.
> Klik-klik-klik dla argumentów konstruktora (ok, ten krok można pominąć i zrobić normalnie w kodzie).
> A w ogóle to wszystko upchane w klasy i więcej jest boilerplate'u, żeby zaspokoić speckę języka, niż kodu, który coś robi.
> Dobra, odpalamy.
> Budowanie przed każdym uruchomieniem.
> Uruchamianie po dokonaniu zmian tylko przez klik-klik w IDE, bo patrz punkt wyżej.
> Powodzenia ze zmianą CWD uruchomienia programu albo przekazaniem argumentu w commandline... Klik-Klik-Klik-Klik-Klik...
> Bo przecież nie chcemy wszystkiego klik-klikać w GUI co uruchomienia prototypu, prawda?
> Więc co, hardkodujemy parametry?... "Przecież to tylko prototyp"?
> A jeszcze Gita dodać... Łomatko!

Brak REPL!

Wiesz, czemu do Pythona nawet nie za bardzo potrzebuję żadnego completion w edytorze?
Bo nawet, jak używam zewnętrznych bibliotek - już pomijając to, że i tak mam otwarte docsy, bo to jest niezależne od języka - mam REPL z complem, w którym mogę przetestować dany statement i natychmiast zobaczyć, jak działa.
Jeśli działa dobrze, to zaznacz-wklej (ciekawe, czy Windows kiedykolwiek dorobi się zaznacz-wklej) do edytora.

Używanie Pythona do prototypowania:
> $ bs -g <nazwa_projektu> py  (oskryptowane)
> Repo gita już zainicjalizowane.
> Przeglądarka, docsy
> REPL
> Ulubiony edytor tekstu

Jeśli kiedyś rzeczywiście zacznę zbierać kontent sam, albo będę musiał/mógł coś z chłopakami(dziewczynom nie ujmując) sklecić, to coś własnego na 100% z tego wyjdzie.
W sensie własny VCS?
Przy obecnym podejściu, to to coś może wyjść mało używalne nawet dla Ciebie...

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +2
# Grudzień 12, 2014, 23:37:19
Cytuj
W sensie własny VCS?
Własny VCS to generalnie fajna sprawa, więc polecam. ;)