Controle de versão para MP3s?

Question

Eu tenho um monte de "mídia binária", que vou abstrair como "MP3s". Eu também tenho vários computadores que eu gostaria de ter toda a biblioteca - uma área de trabalho, caixa de mídia, um laptop aqui ou ali, etc. Em suma, seria bom poder sincronizar todas essas máquinas com cada outro tal que todos eles têm a mesma pilha de arquivos.

Um sistema de controle de versão, em oposição a um lashup de rsync / robocopy, no sentido bruto parece ser o caminho a percorrer. Primeiro, existem vários sistemas operacionais envolvidos (sabores Windows, Mac, Linux). Segundo, seria bom se, quando as tags ID3 e outras fossem atualizadas, o sistema pudesse apenas atualizar o delta do arquivo, e não copiar novamente o arquivo inteiro. (Finalmente, ser capaz de atualizar a biblioteca pela internet, ao invés da lan, seria muito legal.)

Mas seu sistema CVS / SVN clássico tem a óbvia desvantagem de precisar de um repositório completo para funcionar, e eu realmente prefiro não ter duas cópias da minha pasta de 60GB + MP3 em uma máquina em algum lugar, assim como não lidar tradicionalmente com deltas binários muito bem.

Assim, o Controle de Versão Distribuída começa a soar muito bem neste momento. Mercurial , git , e bazaar tudo fica bem no papel, mas eu não tenho nenhum experiência com qualquer um deles. Alguém já tentou configurar um DVCS "somente para binários" com algum deles? Alguma recomendação? Armadilhas?

    

Answer 1

But your classic CVS/SVN system has the obvious drawback of needing a full repository to work, and I'd really rather not have two copies of my 60gb+ MP3 folder sitting on a machine somewhere, as well as not traditionally dealing with binary deltas very well.

Com o CVS / SVN você tem um repositório um e várias cópias de trabalho. Portanto, o repositório contém todos os arquivos uma vez mais todo o histórico de cada arquivo. A cópia de trabalho contém todos os arquivos uma vez mais alguns dados adicionais por arquivo (normalmente aproximadamente o tamanho do arquivo).

Aproximadamente: Vamos supor que nosso sistema de controle de revisão não pode armazenar os arquivos binários de maneira eficiente (não é verdade, mas para simplificar). Sua coleção é de 60 GB de arquivos MP3. Se você tem 10 revisões por arquivo em média e nós negligenciamos a compressão (porque MP3s compactam mal) seu repo será ca. 600 GB e sua cópia de trabalho ca. 120 GB.

So, Distributed Version Control starts sounding pretty good at this point.

Em um sistema distribuído, toda cópia de trabalho é essencialmente um repositório, o que significa cada cópia de trabalho contém todos os arquivos mais o histórico.

As mesmas suposições acima, todas as cópias terão ca. 600 GB.

Em resumo, o sistema distribuído exigirá mais espaço do que o centralizado.

EDITAR:

Mesmo que sua pergunta seja mais sobre um grande número de arquivos binários do que arquivos binários grandes no controle de versão, o seguinte post pode ser interessante: Revisitando problemas com arquivos binários grandes.

    

Answer 2

Esta não é realmente uma resposta à sua pergunta, mas comecei a usar o DropBox para o mesmo propósito. É multi-plataforma, e você pode obter uma conta de 100GB, se você não se importa de pagar um pouco mais. Ele também armazena revisões de arquivos, muito semelhantes ao controle de origem.

    

Answer 3

O problema de tentar encaixar sistemas de controle de versão em sistemas de sincronização de arquivos é que você acabará desperdiçando uma tonelada de espaço em disco mantendo todos os dados do histórico da versão antiga nos repositórios.

Pessoalmente, para minhas grandes coleções de mídia binária, não me importo em poder reverter alterações em um determinado arquivo. Tudo o que me importa é que a coleção esteja sincronizada entre os meus sistemas. Existem muitas soluções de sincronização de arquivos, mas todas elas têm seus vários prós e contras. Alguns afirmam que eles são multi-plataforma, mas isso significa apenas Win / Mac. Outros são realmente de plataforma cruzada, mas não têm limites de tamanho / quantidade de arquivo grandes o suficiente para serem úteis para grandes coleções. Alguns oferecem acesso à Web aos arquivos, mas também sofrem com as limitações de tamanho / quantidade de arquivos. Qualquer solução que mantenha uma cópia dos seus arquivos em um servidor de terceiros inevitavelmente vai lhe custar dinheiro se você tiver uma grande coleção de arquivos.

    

Answer 4

Não é realmente uma resposta, mas pensei em compartilhar. Comecei a usar o SVN para meus projetos de vídeo em HD (como eventos e casamentos, onde o resultado é um vídeo muito editado). Isso está começando a se tornar realmente impressionante por várias razões.

Normalmente, um projeto de vídeo contém algumas ou talvez dezenas ou até centenas de GB de arquivos AVCHD brutos (a maioria com apenas algumas centenas de MB cada, desde que passou de fitas DV;). Estes são adicionados e comprometidos uma vez e depois nunca são alterados, pois todo o trabalho é feito em arquivos de projeto de software de edição de vídeo (muito pequenos e geralmente baseados em texto ou xml), algumas imagens estáticas (que às vezes são alteradas) outros arquivos descritores.

A marcação e a nomeação de clipes também são armazenadas nos arquivos de projeto e não são adicionadas aos arquivos de vídeo brutos reais, o que torna isso ideal. Digamos que um banco de dados do repositório de projetos inicie em 10 GB, ele normalmente terminará em 11 GB e consistirá em ~ 100 revisões. O resultado final renderizado em vários formatos obviamente não é armazenado no repositório, já que ele pode sempre ser gerado novamente.

Como os MP3s, em particular, armazenam seus metadados no arquivo mp3 real, isso representará muito mais um desafio, mas de acordo com esta questão stackoverflow subversion pode lidar com isso decentemente no final como os dados da tag id3 são armazenados no início (ou v1 no final) do arquivo. No entanto, como v2.x pode ser qualquer tamanho - não tenho idéia do que acontece se você adicionar dados de tag adicionais - se o arquivo vai crescer e talvez atrapalhar a comparação delta, vale a pena testar ...

E o armazenamento é barato - apenas 60 GB? Obtenha alguns drives de 1 TB para o repositório e termine com isso;)

    

Answer 5

Windows Vista e amp; 7 oferecem cópia de sombra / versões anteriores. Definitivamente, não é tão rico em recursos como um verdadeiro provedor de controle de origem, mas dá a você alguns dos benefícios. Como outros disseram, o armazenamento necessário para abrigar várias revisões provavelmente será bastante grande - dependendo do tamanho dos arquivos.

Os SCMs gratuitos e populares são todos mais ou menos assim na tarefa. O SVN, por exemplo, funcionará bem, mas o repositório crescerá rapidamente e a pasta .svn local também será bastante grande.

Quando tudo estiver dito e feito, você pode querer considerar simplesmente copiar todo o lote de arquivos para um local seguro antes de fazer grandes alterações em sua coleção; quando você está realmente usando MP3s em uma forma normal do dia-a-dia, não há muita razão para mudar os arquivos e a despesa de ter um sistema de revisão assistindo a arquivos binários grandes e raramente modificados parece difícil de justificar ... mas se você re definido nele, então SVN, pelo menos, faz diff binária, CVS faz cópias completas (muito maior)