Odpowiedzi:
Główną wadą jest miejsce na dysku. Samo repozytorium zajmie tyle samo miejsca, co zestaw plików „pobranych”. Oznacza to, że po sklonowaniu repozytorium Twoja kolekcja zajmie dwa razy więcej miejsca na dysku.
Co gorsza, nawet jeśli usuniesz niepotrzebne pliki, w twoim repozytorium nadal będą znajdować się kopie, zajmujące miejsce.
Możesz przyjrzeć się narzędziom do synchronizacji, takim jak unison, który jest przeznaczony do dwukierunkowej synchronizacji plików na wielu komputerach.
Czy znasz jakieś powody, dla których byłby to zły pomysł?
Git nie nadaje się do takiego użycia.
Sposób działania git polega na tym, że przechowuje dane repozytorium w .git/folderze. W przypadku tekstu nie stanowi to problemu, można go łatwo skompresować, a pliki są małe - repozytorium może być megabajt lub dwa.
Skompresowane dane (MP3, JPEG itp.) Nie mogą być dalej kompresowane przez git, a ponieważ musisz skutecznie przechowywać dwie kopie danych, podwoi to wymaganą ilość miejsca na dysku (jedna dla plików, jedna dla repozytorium)
Tekst jest drobny i ściśliwy, a co ważne, możesz łatwo „różnicować” dwie wersje - tylko przechowując zmiany. Jeśli zmienisz tylko jeden wiersz, git przechowuje tylko ten wiersz (i wszelkie powiązane metadane, takie jak komunikat zatwierdzenia)
Pliki binarne są trudne do odróżnienia, więc powiedzmy, że zmodyfikujesz tagi na 100 plikach (powiedzmy, aby dodać grafikę lub zmienić gatunek), git zapisze nową kopię tych plików w swoim .git/katalogu. Powiedzmy, że usuwasz wszystkie komentarze z metadanych twojej muzyki, git zapisze kolejną kompletną kopię twoich plików! Oznacza to, że Twoje repozytorium będzie teraz ponad dwa razy większe niż rzeczywiste pliki (powiedzmy, że masz 10 GB muzyki, folder muzyki będzie teraz ponad 30 GB)
Jak powiedziałem, git nie nadaje się do takich rzeczy - ma na celu śledzenie kodu źródłowego, z wieloma małymi zmianami w plikach tekstowych, a nie dużymi plikami binarnymi. Przechowywanie historii wersji biblioteki muzycznej nie ma większego sensu, gdy potrzebujesz narzędzia do synchronizacji.
Ponieważ zastanawiasz się nad użyciem git, zakładam, że jesteś wystarczająco zadowolony z narzędzi wiersza poleceń, więc sugeruję skorzystanie z rsync do synchronizacji biblioteki iTunes między komputerami. Największym problemem, jak wspomniano joshhunt, jest to, że iTunes używa bezwzględnych ścieżek do plików multimedialnych, więc iTunes Library.xmlplik zawiera takie rzeczy jak ...
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
Jeśli używasz tego samego systemu operacyjnego i tej samej nazwy użytkownika na wszystkich komputerach, nie stanowi to problemu - utrzymuj pliki w tej samej ścieżce i powinno działać dobrze. Jeśli nie, sprawy stają się nieco bardziej skomplikowane ...
Możesz napisać dwa skrypty, jeden, który aktualizuje ścieżki z komputera A na komputer B i odwrotnie. Możesz przenieść bibliotekę iTunes w inne miejsce, /User/Shared/Music/aby ścieżki były takie same (chociaż może to nie działać w systemie OS X -> Windows)
Istnieje kilka narzędzi do synchronizacji bibliotek iTunes między komputerami, takich jak ..
(z tego artykułu )
Nie jestem pewien, czy Git ma problemy z rozmiarem plików w bibliotece muzycznej (nie działa dobrze z dużymi plikami, ale nie jestem pewien, jak duże), ale Joey Hess napisał program o nazwie załącznik git dla zajmowanie się tego rodzaju przypadkiem użycia.
Systemy kontroli wersji są ogólnie zaprojektowane do obsługi plików tekstowych. Za każdym razem, gdy aktualizujesz plik binarny, musi on utworzyć zupełnie nowy plik, a nie tylko przechowywanie delty.
Przekłada się to na faktyczne wykorzystanie przez bibliotekę dużej ilości miejsca na dysku, jeśli zmieniasz ją regularnie.
Jeśli mówisz tylko o samym pliku biblioteki, może to być OK.
Kolejnym problemem związanym z tą konfiguracją jest to, że iTunes przechowuje swoją bazę danych jako zastrzeżony plik binarny, którego git nie będzie mógł wykonać scalania (nie, zmiany w pliku iTunes Music Library.xml nie zostaną ponownie odczytane przez iTunes) . Tak więc, jeśli dokonałeś zmian w metadanych lub dodałeś dodatkowe ścieżki na obu komputerach, nie byłoby sposobu na pogodzenie zmian dokonanych na obu końcach, w rezultacie nadpisałeś jedną wersję bazy danych drugą, tracąc dane w tym procesie .
Problemy z miejscem na dysku opisane powyżej są z pewnością prawdziwe. Ale są dwa oddzielne problemy. Jednym z nich jest to, że musisz przechowywać repozytorium i dane, więc każdy plik jest przechowywany 2 razy. Drugi problem polega na tym, że za każdym razem, gdy zmieniasz metadane, zapisywana jest cała nowa kopia muzyki, więc stopniowo zapisujesz muzykę N razy, gdzie N stale rośnie. Pierwszy problem może być OK, drugi to prawdziwy problem.
Ciekawe, że chociaż Git ma drugi problem, Subversion nie. Algorytm różnicowania działa na plikach binarnych, więc przechowujesz tylko te zmiany. Dlatego używam Subversion do moich zdjęć, bardzo podobnie do twojego przypadku użycia i jestem z tego bardzo zadowolony.
Oto dziennik ilustrujący problem. Zauważ, że Subversion faktycznie przechowuje trzy kopie: jedną w repozytorium, jedną w katalogach .svn w kopii roboczej i samą kopię roboczą. Nie zmienia to jednak miejsca, ponieważ zmieniam metadane.
mat@Winter:~/temp$ git init repo
Initialized empty Git repository in /home/mat/temp/repo/.git/
mat@Winter:~/temp$ cp -r light_and_magic/ repo/
mat@Winter:~/temp$ cd repo/
mat@Winter:~/temp/repo$ du -hs .
101M .
mat@Winter:~/temp/repo$ git add light_and_magic/
mat@Winter:~/temp/repo$ git commit -m 'First commit'
...
mat@Winter:~/temp/repo$ du -hs .
191M .
mat@Winter:~/temp/repo$ id3v2 -a 'ladytron' light_and_magic/*.mp3
mat@Winter:~/temp/repo$ git commit -a -m 'changed metadata'
...
15 files changed, 0 insertions(+), 0 deletions(-)
mat@Winter:~/temp/repo$ du -hs .
282M .
mat@Winter:~/temp$ svnadmin create repo
mat@Winter:~/temp$ svn co file:///home/mat/temp/repo working
Checked out revision 0.
mat@Winter:~/temp$ cp -r light_and_magic/ working/
mat@Winter:~/temp$ svn add working/light_and_magic/
...
mat@Winter:~/temp$ svn commit -m 'First commit' working/
...
mat@Winter:~/temp$ du -hs repo
91M repo
mat@Winter:~/temp$ du -hs working/
201M working/
mat@Winter:~/temp$ id3v2 -a 'ladytron' working/light_and_magic/*.mp3
mat@Winter:~/temp$ svn commit -m 'changed metadata' working/
...
mat@Winter:~/temp$ du -hs repo/
91M repo/
mat@Winter:~/temp$ du -hs working/
201M working/