Pergunta

Eu tenho um repositório mercurial para um projeto pessoal e tenho armazenado o repositório mestre no meu dropbox há algumas semanas (algo junto está linha; E eu entendo que também é possível com git).

A idéia é que ela serve tanto como uma maneira de trabalhar com várias máquinas quanto como um backup remoto. Clonei o repositório e trabalho na cópia que não é do Dropbox, e pressiono apenas as atualizações de vez em quando, da mesma maneira que faria, suponho, trabalho com o Bitbucket.

Você consegue pensar em alguma desvantagem dessa idéia, em comparação com o uso de hospedagem dedicando (Bitbucket no caso do Mercurial)? Eu sei que o Bitbucket tem contas gratuitas para usuários únicos, o que é ótimo, mas eles são limitados a 150m, o que não é um enorme.

Em particular, é possível que o processo de sincronização do Dropbox corrompe o repositório? Eu tive que correr Hg recuperar uma vez no repositório mestre, mas pode não estar relacionado (e de qualquer maneira se recuperou felizmente). Alguém tem uma experiência ruim com a ideia? Alguém tem uma experiência mais longa e pode aliviar minhas preocupações? Alguém tem uma opinião baseada em uma melhor compreensão dos internos dessas coisas?

EDIT: Eu adicionei alguns esclarecimentos às perguntas. Eles estão dentro itálico.

Foi útil?

Solução

Aconselho contra isso pelas razões declaradas acima, mas declaradas com mais força. Mercurial e Git têm seus próprios protocolos para mover mudanças entre os repositórios. Esses protocolos são otimizados/construídos para:

  • eficiência
  • Consistência (nunca você pode puxar de um repo em um estado meio atualizado)
  • ganchos/gatilhos - fazendo coisas em push/pull, incluindo qualidade (sem guias permitidas, etc.) filtros

Quando você apenas deixa uma sincronização de diretório manipular a manutenção dos diretórios .hg (ou .git) em sincronia e, durante essa sincronização, você tem uma loja remota que está em um estado inconsistente e não sabe disso.

Além disso, o HG e o Git têm uma separação do que é apenas local e o que é okay remoto dentro do estado de disco. Eles sabem quais informações compartilhar (exemplo: alterações cometidas) e o que não é (exemplo: revisão atual do diretório de trabalho local).

Em outras respostas, as pessoas estão dizendo "você provavelmente ficará bem" ou "Eu nunca tive um problema" e isso provavelmente é verdade, mas não é garantido, e o controle de revisão não é um lugar para reproduzir as chances. Use o protocolo de sincronização adequado, melhor, seguro, mais eficiente e mais completo em destaque para o seu sistema de controle de origem.

Outras dicas

Eu tive problemas com os meus repositórios do Dropbox se tornando corrompido. Isso não acontece o tempo todo, mas o fato de ter acontecido mais de uma vez significa que vou parar de usar o Dropbox para esse fim.

Dito isto, o Dropbox é certamente mais barato do que receber hospedagem real; portanto, desde que você mantenha backups, você pode achar aceitável para projetos pessoais.

Suponho que isso provavelmente funcionaria bem para projetos pessoais em uma ou duas máquinas, mas na verdade você vai querer usar a hospedagem profissional para projetos de vários membros.

Eu pessoalmente usei o Bitbucket há algum tempo e fiquei bastante satisfeito ... você também pode ter um projeto privado na conta gratuita.

Eu esperaria problemas se você tentar acessar o repositório no meio da sincronização. Também parece ser um pouco de sobrecarga. Você realmente não precisa sincronizar as coisas que sincroniza. Não tenho idéia de como o Dropbox lida com conflitos, mas duvido que isso possa fazê-lo de maneira consciente do SCM.

+1 para Bitbucket. É gratuito e você recebe um único repositório privado com essa conta gratuita (ao contrário do Github).

A desvantagem com a solução Somente o Dropbox é que, se você estragar algo no repositório da sua máquina, essa aparafusa será copiada para o Bitbucket e replicada para todos os outros lugares que você instalou o Dropbox. O Dropbox é muito rápido, para que você não possa impedir que isso aconteça a tempo de evitar problemas.

Você perde a capacidade de dissipar as alterações em seu repositório com a publicação dessas alterações.

Eu uso o Dropbox para hospedar alguns repositórios que uso nas máquinas de casa e de trabalho, mas essas não são as únicas cópias desses repositórios. Há também um repo Bitbucket (assim como outras pessoas que têm clones deles).

Também uso o Dropbox com HG sem ter um problema até agora. Tarde demais, percebi que o HG não relata a corrupção durante as verificações de rotina, somente quando você tenta usar o repositório de verdade (o pior de todas as situações, já que você não sabe que algo está quebrado até que realmente precisa).

Não está claro se a corrupção é espontânea ou causada pelo acesso ao repositório com clientes Mac, Windows e Linux (eu uso os três em momentos diferentes). Mas eu já vi pelo menos um caso de corrupção acontecendo quando apenas o Mac estava ativo, por isso poderia ser o próprio Dropbox.

Se você decidir viver perigosamente, execute "hg verifique" (ou "git verifique" regularmente para aumentar a sujeira.

Estou usando o Dropbox com o Git para projetos pessoais há algum tempo e ainda não tive um único problema. Embora haja momentos em que você deve esperar o Dropbox sincronizar. EU acho Isso pode causar problemas menores se houver mais do que algumas pessoas trabalhando no mesmo projeto, mas para projetos pessoais, acho que o Dropbox é ainda melhor que o Github, mesmo que apenas pelo fato de empurrar/puxar é mais rápido.

Quanto a empurrar/puxar o meio-sincronizar, isso provavelmente causará problemas, e pode até corromper seu repositório, mas se você é o único que trabalha no projeto, sabe exatamente quando o Dropbox será sincronizado.

Eu não recomendaria o uso do Dropbox com o Mercurial, pois muitas vezes vejo arquivos conflitantes entre meus clientes Mac e Windows. Especialmente o desfazer é afetado, mas também experimentei conflitos com outros arquivos.

Atenciosamente Mirko

Estou usando -o com o bazar no momento em três máquinas. No entanto, sou o desenvolvedor solitário em qualquer um dos ramos.

Eu usei o comando init-repo--não-árvores para criar o repositório.

Para aqueles que preferem usar o Dropbox sobre o Bitbucket/Github, eis o que faço para evitar a corrupção do processo de sincronização bidirecional dos serviços de backup em nuvem:

Minha pasta de código local é c:\code Pasta de backup é c:\Dropbox. Dentro da pasta Dropbox, eu tenho um TrueCrypt Contêiner de arquivo criptografado (seu tamanho é suficientemente maior que a minha pasta de código). Durante o dia, comprometo regularmente mudanças no meu repositório local/mercurial. No entanto, no final do dia, saí de Dropbox e montei o contêiner de arquivo TrueCrypt. Eu pressiono as alterações para um repositório nu no contêiner de arquivo, desmontei e reinicio o Dropbox.

Dessa forma, posso usar um serviço em nuvem com segurança para servir como um backup do meu repositório DVCS. Se o contêiner de arquivos estiver em uso, o Dropbox aguardará que ele seja desmontado, por isso espero que não haja alteração de corrupção lá. Ainda assim, se eu receber uma cópia conflitada do contêiner de arquivo, de alguma forma, posso montar facilmente as cópias e comparar o conjunto de alterações.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top