Dropboxを使ったMercurial（そしてGitだと思います）：欠点はありますか？
私は個人プロジェクト用のMercurialリポジトリを持っており、マスターリポジトリをDropboxに数週間保存しています（ この行 ;そしてそれも 可能性があるgit ）。
アイデアは、複数のマシンで作業する方法とリモートバックアップの両方として機能するということです。 リポジトリのクローンを作成してDropbox以外のコピーで作業し、Bitbucketで作業するのと同じように、たまに更新をプッシュするだけです。
専用ホスティング（Mercurialの場合はBitBucket）を使用する場合と比較して、このアイデアの欠点を思いつくことができますか？ Bitbucketにはシングルユーザー用の無料アカウントがあることは知っていますが、これは素晴らしいことですが、1億5000万に制限されており、それほど大きくはありません。
特に、Dropboxの同期プロセスがリポジトリを破壊する可能性はありますか？マスターリポジトリでhg restoreを1回実行する必要がありましたが、無関係である可能性があります（とにかく正常に回復しました）。誰かがそのアイデアで悪い経験をしていますか？誰かがより長い良い経験をしていて、私の心配を軽減することができますか？これらのものの内部のより良い理解に基づいて誰かが意見を持っていますか？
編集：質問にいくつかの説明を追加しました。それらはイタリックにあります。
上記の理由で反対することをお勧めしますが、もっと熱心に述べています。 Mercurialとgitの両方に、リポジトリ間でチェンジセットを移動するための独自のプロトコルがあります。これらのプロトコルは、次の目的で最適化/構築されています。
- 効率
- 一貫性（半分更新された状態のリポジトリからプルすることはできません）
- フック/トリガー-品質（タブは許可されていないなど）フィルターを含むプッシュ/プルでの処理
ディレクトリ同期に.hg（または.git）ディレクトリの同期の維持を処理させると、その同期中に、一貫性のない状態にあり、それを認識しないリモートストアが発生します。
さらに、hgとgitはどちらも、ディスク状態内でローカルのみのものとリモートのものを分離しています。彼らは、共有する情報（例：コミットされたチェンジセット）と共有しない情報（例：現在のローカル作業ディレクトリの親リビジョン）を知っています。
他の回答では、人々は「おそらく大丈夫だろう」または「私は問題を起こしたことがない」と言っており、それはおそらく真実ですが、それは真実であるとは限らず、リビジョン管理はオッズをプレイする場所ではありません。ソース管理システムには、適切で、より良く、より安全で、より効率的で、よりフル機能の同期プロトコルを使用してください。
Dropboxのリポジトリが破損するという問題が発生しました。常に発生するわけではありませんが、複数回発生しているということは、この目的でDropboxの使用をやめることを意味します。
とは言うものの、Dropboxは実際のホスティングを利用するよりも確かに安価であり、バックアップを保持している限り、個人的なプロジェクトに受け入れられる可能性があります。
1台または2台のマシンでの個人的なプロジェクトではおそらく問題なく機能すると思いますが、実際には、マルチメンバープロジェクトではプロのホスティングを使用する必要があります。
私はしばらくの間BitBucketを個人的に使用していて、非常に満足しています...無料アカウントで1つのプライベートプロジェクトを持つこともできます。
bitbucketの場合は+1。それは無料で、その無料アカウントで単一のプライベートリポジトリを取得します（githubとは異なります）。
ドロップボックスのみのソリューションの欠点は、マシンのリポジトリで何かを台無しにした場合、その台無しがビットバケットにコピーされ、ドロップボックスがインストールされている他のすべての場所に複製されることです。 Dropboxは非常に高速なので、問題を防ぐために時間内に発生するのを止めることはできません。
リポジトリへの変更を公開することで、それらの変更を切り離すことができなくなります。
私はdropboxを使用して、自宅と職場の両方のマシンで使用するいくつかのリポジトリをホストしていますが、それらのリポジトリのコピーはそれらだけではありません。 bitbucketリポジトリ（およびそれらのクローンを持っている他の人々）もあります。
同期の途中でリポジトリにアクセスしようとすると、問題が発生することが予想されます。また、少しオーバーヘッドがあるようです。同期するものを同期する必要はありません。 dropboxが競合をどのように処理するかはわかりませんが、scm対応の方法で処理できるとは思えません。
私もこれまで問題なくDropboxをHgで使ってきました。遅すぎて、hgが定期的なチェックイン中に破損を報告しないことに気付きました。これは、リポジトリを実際に使用しようとした場合のみです（本当に必要になるまで何かが壊れていることがわからないため、すべての状況で最悪です）。
破損が自然発生的なものなのか、Mac、Windows、Linuxクライアントでリポジトリにアクセスしたことが原因なのかは明確ではありません（私は3つすべてを異なる時間に使用しています）。しかし、Macだけがアクティブだったときに、少なくとも1つの破損が発生したので、Dropbox自体である可能性があります。
危険な生活を送ることにした場合は、「hgverify」（または「gitverify」）を定期的に実行して汚れを見つけてください。
私はかなり長い間、個人的なプロジェクトにgitでDropboxを使用してきましたが、まだ1つの問題は発生していません。ただし、Dropboxが同期するのを待たなければならない場合があります。 I think同じプロジェクトに取り組んでいる人が少なすぎる場合、これは小さな問題を引き起こす可能性がありますが、個人的なプロジェクトの場合、プッシュするという事実だけを考えれば、DropboxはGitHubよりも優れていることがわかります/ pullingの方が高速です。
同期中のプッシュ/プルに関しては、これはおそらく問題を引き起こし、リポジトリを破壊する可能性さえありますが、プロジェクトに取り組んでいるのがあなただけの場合は、Dropboxがいつ同期するかを正確に知っています。
MacとWindowsクライアント間でファイルの競合が頻繁に発生するため、Mercurialでdropboxを使用することはお勧めしません。特に元に戻すことが影響を受けますが、他のファイルとの競合も経験しました。
よろしくミルコ
現在、3台のマシンでBazaarで使用しています。しかし、私はどのブランチでも唯一の開発者です。
Init-repo--no-treesコマンドを使用してリポジトリを作成しました。
Bitbucket/githubよりもDropboxを使用することを好む人のために、クラウドバックアップサービスの双方向同期プロセスによる破損を回避するために私が行うことは次のとおりです。
私のローカルコードフォルダはc:\code＆バックアップフォルダはc:\Dropbox。 Dropboxフォルダー内に truecrypt 暗号化されたファイルコンテナーがあります（サイズはコードフォルダーよりも十分に大きいです）。日中、私は定期的にローカルのGit/Mercurialリポジトリに変更をコミットします。しかし、結局のところ、私はDropboxを終了し、truecryptファイルコンテナーをマウントします。変更をファイルコンテナ内のベアリポジトリにプッシュし、マウントを解除してDropboxを再起動します。
そうすれば、DVCSリポジトリのバックアップとして機能するクラウドサービスを安全に使用できます。ファイルコンテナが使用中の場合、Dropboxはそれがアンマウントされるのを待つので、うまくいけば、そこに破損の変化はありません。それでも、何らかの理由でファイルコンテナの競合するコピーを取得した場合は、両方のコピーを簡単にマウントして、変更セットを比較できます。