Respostas:
A principal desvantagem é o espaço em disco. O próprio repositório ocupará a mesma quantidade de espaço que o conjunto de arquivos "retirados". Isso significa que, quando você clona o repositório, sua coleção ocupa basicamente o dobro do espaço em disco.
Pior ainda, mesmo se você excluir os arquivos que não deseja mais, ainda haverá cópias no seu repositório, ocupando espaço.
Você pode querer olhar para ferramentas de sincronização como uníssono, projetada para sincronização bidirecional de arquivos em várias máquinas.
Você pode pensar em alguma razão pela qual isso seria uma má idéia?
Git não é adequado para esse uso.
A maneira como o git funciona é que ele mantém os dados do repositório na .git/pasta. Com o texto, isso não é problema, pode ser compactado facilmente e os arquivos são pequenos - o repositório pode ser um megabyte ou dois.
Os dados compactados (MP3s, JPEGs etc.) não podem ser mais compactados pelo git e, como você precisa efetivamente armazenar duas cópias dos dados, isso duplicará o espaço em disco necessário (um para os arquivos e outro para o repositório)
O texto é minúsculo, compactável e, o mais importante é que você pode "diferenciar" facilmente entre duas revisões - apenas armazenando as alterações. Se você alterar apenas uma linha, o git armazenará apenas essa linha (e quaisquer metadados associados, como a mensagem de confirmação)
Os arquivos binários são difíceis de diferenciar; portanto, digamos que você modifique as tags em 100 arquivos (por exemplo, para adicionar ilustrações ou alterar um gênero), o git armazenará uma nova cópia desses arquivos em seu .git/diretório. Digamos que você retire todos os comentários dos metadados da sua música, o git armazenará outra cópia completa dos seus arquivos! Isso significa que seu repositório terá agora o dobro do tamanho dos arquivos reais (digamos que você tenha 10 GB de música, sua pasta de músicas terá mais de 30 GB)
Como eu disse, o git não é adequado para essas coisas - ele visa rastrear o código-fonte, com muitas pequenas alterações nos arquivos de texto, não nos grandes arquivos binários. Não faz muito sentido manter um histórico de revisões da sua biblioteca de músicas, quando tudo o que você precisa é de uma ferramenta de sincronização.
Como você está pensando em usar o git, presumo que você esteja feliz o suficiente com as ferramentas de linha de comando, então sugiro que você use o rsync para sincronizar sua biblioteca do iTunes entre as máquinas. O maior problema, como joshhunt mencionado, é o iTunes usa caminhos absolutos para arquivos de mídia, portanto o iTunes Library.xmlarquivo contém coisas como ..
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
Se você usa o mesmo sistema operacional e o mesmo nome de usuário em todas as máquinas, isso não é problema - mantenha os arquivos no mesmo caminho e deve funcionar bem. Caso contrário, as coisas ficam um pouco mais complicadas ..
Você pode escrever dois scripts, um que atualiza os caminhos da máquina A para a máquina B e vice-versa. Você pode mover a sua biblioteca do iTunes para outro local, /User/Shared/Music/para que os caminhos sejam os mesmos (embora isso possa não funcionar no OS X -> Windows)
Existem alguns utilitários para sincronizar as bibliotecas do iTunes entre máquinas, como ..
( deste artigo )
Os sistemas de controle de versão em geral são projetados para manipular arquivos de texto. Toda vez que você atualiza um arquivo binário, ele precisa criar um arquivo completamente novo, em vez de apenas armazenar um delta.
Como isso se traduz no uso no mundo real é que sua biblioteca usaria muito espaço em disco se você a alterasse regularmente.
Se você estiver falando apenas do próprio arquivo da biblioteca, isso pode estar OK.
Mais um problema com essa configuração é que o iTunes armazena seu banco de dados como um arquivo binário proprietário no qual o git não poderá realizar a fusão (não, as edições no arquivo iTunes Music Library.xml não serão lidas novamente pelo iTunes) . Portanto, se você fizesse alterações nos metadados ou adicionasse faixas adicionais nas duas máquinas, não haveria maneira de reconciliar as alterações feitas nas duas extremidades, você acabaria substituindo uma versão do banco de dados pela outra e perdendo dados no processo. .
Os problemas de espaço em disco descritos acima são certamente verdadeiros. Mas existem dois problemas separados. Uma é que você precisa armazenar o repositório e os dados, para que cada arquivo seja armazenado 2 vezes. O segundo problema é que, toda vez que você altera seus metadados, uma cópia totalmente nova da música é armazenada; assim, gradualmente, você acaba armazenando sua música N vezes, onde N aumenta continuamente. O primeiro problema pode ser bom, o segundo é uma chatice real.
Portanto, é interessante que, embora o Git sofra do segundo problema, o Subversion não. Seu algoritmo diff funciona em arquivos binários, então você armazena apenas o que muda. É por isso que uso o Subversion para minhas fotos, muito semelhante ao seu caso de uso, e estou muito feliz com isso.
Aqui está um log que ilustra o problema. Note que o Subversion na verdade armazena três cópias: uma no repositório, uma nos diretórios .svn na cópia de trabalho e a própria cópia de trabalho. No entanto, ele não usa espaço extra, pois altero os metadados.
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/