Controle de versão e backup, qual combinação?

Question

Sou um único desenvolvedor e tenho 3 computadores. Além disso, um amigo meu tem uma conta, mas nunca a usa. Minha configuração atual é o GIT + meu próprio trabalho de backup ad hoc que clona o repositório, fecha, gnupg e envia para um ftp remoto. Isso funcionou muito bem até agora apenas para o meu código-fonte / arquivos docbook / xml + arquivos binários menores (principalmente ícones + algumas imagens para uso com o docbook).

No entanto, recentemente me envolvi em um projeto de jogo em flash e criei um repositório apenas para ele, mas os arquivos flash FLA são enormes (eu vi +70 MB). E o git reempacotado com um tamanho de janela baixo não pode mais ser concluído. Ainda mais eu descobri que alguns dos meus arquivos usa retorno de carro em vez de alimentação de linha e GIT não está feliz em diferenciar esses arquivos. Quando eu criei o repositório, eu deveria configurá-lo para converter automaticamente CR para LF em commit. No entanto, eu não sabia desses problemas.

Fora do desespero, experimentei o Mercurial, mas o tamanho máximo do arquivo é de 10 MB.

Estou pensando em dividir meus projetos em arquivos binários e mantê-los na subversão, já que parece bom em arquivos binários. E o código fonte no GIT. Mas esta será uma tarefa enorme e soa como um plano ruim de alguma forma.

Qual sistema de controle de versão você usa? Como você faz o backup? e o que você faz com seus arquivos binários?

    

Answer 1

Isso é def. um plano ruim, dividindo seus sistemas de controle de versão!

Nós enviamos arquivos binários através do SVN todos os dias onde estamos, alguns deles são grandes também. É claro que você não pode diferenciar um arquivo binário, e se seu arquivo binário é 20mb, toda vez que você o confirmar, você precisará de outros 20mb de espaço no seu servidor subversion.

Quanto aos nossos backups, apenas executamos um SVNumpump todas as noites, compactamos e carregamos de forma semelhante ao que você faz.

Tudo o que foi dito é que talvez seja uma questão melhor para os caras do Stack Overflow , pois eles são usuários de VC mais pesados do que nós estão em SF!

(Não se estresse em recriar essa pergunta, se pessoas suficientes concordarem que ela será movida automaticamente).

    

Answer 2

Em relação ao CRLF - veja git-config (1), especificamente a opção "core.autocrlf", que pode ser usada para alternar o comportamento de conversão.

    

Answer 3

Você quer que seus arquivos de 70M sejam armazenados em backup, certo? Em caso afirmativo, qualquer que seja o esquema usado, você irá copiá-los para o site FTP pelo menos uma vez. Se eles são compressíveis, é provável que o git faça quase o melhor trabalho de compactá-los, o que é praticamente possível.

Para evitar a cópia de todo o repositório para o seu site FTP para cada backup, eu verificaria

1. se possível, usando "git push" para o site de backup ou "git pull" do site de backup, se você puder instalar o git nele. Isso só enviará o material que está faltando e não enviará repetidamente os arquivos de 70M.
2. Se isso não for possível, existe algum software que pode enviar um diferencial através de protocolos "burros" como o FTP. Eu estava envolvido em escrever um muitos, muitos anos atrás chamado 'syncftp' (syncftp.sf.net). Meu amigo Simon (que escreveu a maior parte do syncftp) passou a escrever outra ferramenta chamada 'gsync'. Há também 'sitecopy', link . Uma ressalva: você vai querer configurar seu git para que ele não reembale muito os arquivos juntos, já que o processo de cópia será baseado em arquivos, e se um arquivo de pacote mudar um pouco, ele copia a coisa toda. Assim, você perderá algumas eficiências de empacotamento no repositório, para ganhar alguma eficiência no uso de largura de banda de backup.

(salvarei seus arquivos CRLF para outra resposta)