Mercurial (et, je suppose, Git) avec Dropbox : des inconvénients ?

Question

J'ai un dépôt Mercurial pour un projet personnel, et je stocke le dépôt principal dans ma Dropbox depuis quelques semaines maintenant (quelque chose du type cette ligne et je comprends que c'est aussi possible avec git ).

L'idée est qu'il sert à la fois de moyen de travailler avec plusieurs machines et de sauvegarde à distance. Je clone le dépôt et je travaille sur la copie non-Dropbox, et je ne pousse les mises à jour que de temps en temps, de la même manière que je travaillerais, je suppose, avec Bitbucket.

Pouvez-vous penser à des inconvénients de cette idée, par rapport à l'utilisation d'un hébergement dédié (BitBucket dans le cas de Mercurial) ? Je sais que Bitbucket propose des comptes gratuits pour les utilisateurs uniques, ce qui est très bien, mais ils sont limités à 150M, ce qui n'est pas énorme. .

En particulier, est-il possible que le processus de synchronisation de Dropbox corrompe le référentiel ? J'ai dû exécuter hg récupérer une fois sur le dépôt maître, mais cela pourrait ne pas être lié (et de toute façon, il a été heureusement récupéré). Quelqu'un a-t-il une mauvaise expérience avec cette idée ? Est-ce que quelqu'un a une bonne expérience plus longue et peut atténuer mes inquiétudes ? Quelqu'un a-t-il une opinion basée sur une meilleure compréhension de l'intérieur de ces choses ?

edit : J'ai ajouté quelques clarifications aux questions. Elles sont dans italiques .

Answer 1

Je vous le déconseille pour les raisons énoncées plus haut, mais de façon plus prononcée. Mercurial et Git ont tous deux leurs propres protocoles pour déplacer les jeux de modifications entre les dépôts. Ces protocoles sont optimisés/construits pour :

• efficacité
• la cohérence (vous ne pouvez jamais tirer d'un repo à moitié mis à jour)
• hooks/triggers -- faire des choses en push/pull y compris les filtres de qualité (pas de tabs autorisés, etc.)

Lorsque vous laissez simplement une synchronisation de répertoire s'occuper de la synchronisation des répertoires .hg (ou .git), pendant cette synchronisation, vous avez un magasin distant qui est dans un état incohérent et qui ne le sait pas.

De plus, hg et git ont tous deux une séparation entre ce qui est local uniquement et ce qui est distant dans leur état de disque. Ils savent quelles informations partager (exemple : les jeux de modifications commités) et ce qu'il ne faut pas partager (exemple : la révision parentale actuelle du répertoire de travail local).

Dans d'autres réponses, les gens disent "ça va probablement aller" ou "je n'ai jamais eu de problème" et c'est probablement vrai, mais ce n'est pas garanti, et le contrôle de révision n'est pas un endroit pour jouer les chances. Utilisez le protocole de synchronisation approprié, meilleur, plus sûr, plus efficace et plus complet pour votre système de contrôle du code source.

Answer 2

J'ai eu des problèmes avec mes dépôts Dropbox'ed corrompus. Cela n'arrive pas tout le temps, mais le fait que cela se soit produit plus d'une fois signifie que je vais cesser d'utiliser Dropbox à cette fin.

Cela dit, Dropbox est certainement moins cher qu'un véritable hébergement, et tant que vous conservez des sauvegardes, vous pouvez le trouver acceptable pour vos projets personnels.

Answer 3

Je suppose que cela pourrait fonctionner pour des projets personnels sur une ou deux machines, mais il est préférable d'utiliser un hébergement professionnel pour les projets à plusieurs membres.

J'utilise personnellement BitBucket depuis un certain temps et j'en suis très satisfait... Vous pouvez également avoir un projet privé sur le compte gratuit.

Answer 4

Je m'attends à des problèmes si vous essayez d'accéder au référentiel au milieu de la synchronisation. Cela semble également être un peu de surcharge. Vous n'avez pas vraiment besoin de synchroniser les choses que vous synchronisez. Je n'ai aucune idée de la façon dont Dropbox gère les conflits, mais je doute qu'il puisse le faire d'une manière adaptée à Scm.

Answer 5

+1 pour bitbucket. C'est gratuit et vous disposez d'un seul repo privé avec ce compte gratuit (contrairement à github).

L'inconvénient de la solution Dropbox uniquement est que si vous faites une erreur dans le dépôt sur votre machine, cette erreur sera copiée sur Bitbucket et reproduite à tous les autres endroits où Dropbox est installé. Dropbox est très rapide, vous ne pourrez donc pas l'empêcher de se produire à temps pour éviter les problèmes.

Vous perdez la possibilité de découpler les modifications apportées à votre référentiel avec la publication de ces modifications.

J'utilise Dropbox pour héberger quelques dépôts que j'utilise à la fois sur mes machines personnelles et professionnelles, mais ce ne sont pas les seules copies de ces dépôts. Il y a aussi un dépôt bitbucket (ainsi que d'autres personnes qui en ont des clones).