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

J’ai un repository Mercurial pour un projet personnel et je stocke le référentiel maître dans mon Dropbox depuis quelques semaines (quelque chose dans ce sens , et je comprends que c’est également possible avec git ).

L’idée est qu’il sert à la fois de travail avec plusieurs machines et de sauvegarde à distance. Je clone le référentiel et travaille sur la copie non-Dropbox, et ne pousse les mises à jour que de temps en temps, de la même manière que je suppose, je suppose, avec Bitbucket.

Pouvez-vous penser à des inconvénients par rapport à l’utilisation de l’hébergement dédicacé (BitBucket dans le cas de Mercurial)? Je sais que Bitbucket a des comptes gratuits pour les utilisateurs individuels, ce qui est bien, mais ils sont limités à 150 millions, 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 recover une fois sur le référentiel maître, mais cela peut ne pas être le cas (et de toute façon, il a été récupéré). Est-ce que quelqu’un a une mauvaise expérience avec l’idée? Est-ce que quelqu’un a une meilleure expérience et peut atténuer mes soucis? Est-ce que quelqu’un a une opinion basée sur une meilleure compréhension de l’intérieur de ces choses?

edit: J’ai ajouté des clarifications aux questions. Ils sont en italique .

Je le déconseillerais pour les raisons indiquées ci-dessus, mais plus énergiquement. Mercurial et Git ont tous deux leurs propres protocoles pour déplacer les ensembles de modifications entre les référentiels. Ces protocoles sont optimisés / construits pour:

  • Efficacité
  • cohérence (ne peut jamais tirer d’un repo dans un état à moitié mis à jour)
  • crochets / déclencheurs – faire des choses en poussant / tirant, y compris la qualité (pas d’tabs autorisés, etc.)

Lorsque vous laissez simplement une synchronisation de répertoire gérer la conservation des répertoires .hg (ou .git) synchronisés, vous disposez alors d’un magasin distant dans un état incohérent et qui ne le connaît pas.

De plus, hg et git ont une séparation entre ce qui est uniquement local et ce qui est correct dans leur état de disque. Ils connaissent les informations à partager (exemple: modifications apscopes à un committent) et ce qu’il ne faut pas (exemple: révision parent actuelle du répertoire de travail local).

Dans d’autres réponses, les gens disent “vous allez probablement aller bien” ou “je n’ai jamais eu de problème” et c’est probablement vrai, mais ce n’est pas garanti, et le contrôle des révisions n’est pas un endroit pour jouer. Utilisez le protocole de synchronisation approprié, meilleur, plus sûr, plus efficace et plus complet pour votre système de contrôle de source.

J’ai rencontré des problèmes avec la corruption de mes repositorys Dropbox. Cela n’arrive pas tout le temps, mais le fait que cela soit arrivé plus d’une fois signifie que je vais cesser d’utiliser Dropbox à cette fin.

Cela dit, Dropbox est certainement moins cher que d’obtenir un véritable hébergement, aussi longtemps que vous conservez des sauvegardes, vous pouvez le trouver acceptable pour des projets personnels.

Je suppose que cela fonctionnerait probablement bien pour des projets personnels sur une ou deux machines, mais en réalité, vous allez vouloir utiliser un hébergement professionnel pour des projets multi-membres.

J’ai personnellement utilisé BitBucket pendant un certain temps et j’ai été très satisfait … vous pouvez également avoir un projet privé sur le compte gratuit.

Je m’attendrais à des problèmes si vous essayez d’accéder au référentiel au milieu de la synchronisation. Il semble aussi y avoir un peu de frais généraux. 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 de manière scm.

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

L’inconvénient de la seule solution de la boîte de repository est que si vous déposez quelque chose dans le repo sur votre machine, cette opération sera copiée sur bitbucket et répliquée partout où la boîte de repository est installée. Dropbox est très rapide, vous ne pourrez donc pas l’empêcher de se produire à temps pour éviter les problèmes.

Vous ne pouvez plus découpler les modifications apscopes à votre référentiel en publiant ces modifications.

J’utilise dropbox pour héberger quelques référentiels que j’utilise à la fois sur mes machines domestiques et professionnelles, mais ce ne sont pas les seules copies de ces référentiels. Il y a aussi un repo bitbucket (ainsi que d’autres personnes qui ont des clones).

J’ai utilisé Dropbox avec Hg aussi sans avoir rencontré de problème jusqu’à maintenant. Trop tard, je me suis rendu compte que hg ne signalait pas de corruption lors des checkins de routine, uniquement lorsque vous essayez d’utiliser le repo pour de vrai (la pire des situations, puisque vous ne savez pas que quelque chose est cassé).

Ce n’est pas clair si la corruption est spontanée ou causée par l’access au référentiel avec les clients Mac, Windows et Linux (je les utilise tous les trois à des moments différents). Mais j’ai vu au moins un cas de corruption se produire lorsque seul le Mac était actif, il se pourrait donc que ce soit Dropbox lui-même.

Si vous décidez de vivre dangereusement, lancez “hg verify” (ou “git verify” régulièrement pour augmenter la saleté).

J’utilise Dropbox avec git pour des projets personnels depuis un certain temps déjà, et je n’ai pas encore eu de problème. Bien que, parfois, vous devez attendre que Dropbox se synchronise. Je pense que cela peut causer des problèmes mineurs s’il y a plus que quelques personnes travaillant sur le même projet, mais pour des projets personnels, je trouve Dropbox encore meilleur que GitHub, ne serait-ce que parce que pousser / tirer est plus rapide.

En ce qui concerne le push / mid-sync, cela causera très probablement des problèmes, et il pourrait même corrompre votre repository, mais si vous êtes le seul à travailler sur le projet, vous saurez exactement quand Dropbox se synchronisera.

Je ne recommanderais pas d’utiliser dropbox avec mercurial, car je vois souvent des fichiers en conflit entre mes clients Mac et Windows. En particulier, l’annulation est affectée, mais j’ai également rencontré des conflits avec d’autres fichiers.

Cordialement Mirko

Je l’utilise actuellement avec Bazaar sur 3 machines. Cependant, je suis le seul développeur dans l’une des twigs.

J’ai utilisé la commande init-repo –no-trees pour créer le référentiel.

Pour ceux qui préfèrent utiliser Dropbox sur bitbucket / github, voici ce que je fais pour éviter la corruption du processus de synchronisation bidirectionnel des services de sauvegarde sur le cloud:

Mon dossier de code local est c:\code et le dossier de sauvegarde est c:\Dropbox . Dans le dossier Dropbox, j’ai un conteneur de fichiers crypté par truecrypt (sa taille est suffisamment plus grande que mon dossier de code). Au cours de la journée, je confie régulièrement des modifications à mon référentiel Git / Mercurial local. Cependant, à la fin de la journée, je quitte Dropbox et monte le conteneur de fichiers truecrypt. Je pousse les modifications vers un référentiel dénudé dans le conteneur de fichiers, le démonte et redémarre Dropbox.

De cette façon, je peux utiliser un service cloud en toute sécurité pour servir de sauvegarde de mon référentiel DVCS. Si le conteneur de fichiers est en cours d’utilisation, Dropbox attendra qu’il soit démonté. Cependant, si je reçois une copie du conteneur de fichiers en conflit, je peux facilement monter les deux copies et comparer les modifications.