62

私は個人プロジェクト用の Mercurial リポジトリを持っており、マスター リポジトリを Dropbox に数週間保存しています (この線に沿った何か; gitでも可能であることは理解しています)。

アイデアは、複数のマシンで作業する方法とリモート バックアップの両方として機能するということです。リポジトリのクローンを作成し、Dropbox 以外のコピーで作業し、Bitbucket で作業する場合と同じように、たまに更新をプッシュするだけにします。

専用ホスティング (Mercurial の場合は BitBucket) を使用する場合と比較して、このアイデアの欠点は何か考えられますか? Bitbucket には単一ユーザー用の無料アカウントがあることは知っていますが、これは素晴らしいことですが、150M に制限されており、それほど大きくはありません。

特に、Dropbox の同期プロセスによってリポジトリが破損する可能性はありますか? マスター リポジトリでhg recoverを 1 回実行する必要がありましたが、それは無関係かもしれません (とにかく、無事に回復しました)。誰かがそのアイデアで悪い経験をしていますか? 誰かがより長く良い経験をして、私の心配を和らげることができますか? これらの内部構造をよりよく理解することに基づいて意見を持っている人はいますか?

編集：質問にいくつかの説明を追加しました。それらは斜体で示されています。

4

10 に答える 10

75

上記の理由から、私はそれに反対することをお勧めしますが、もっと激しく述べています。Mercurial と git の両方に、リポジトリ間で変更セットを移動するための独自のプロトコルがあります。これらのプロトコルは、次の目的で最適化/構築されています。

  • 効率
  • 一貫性 (半分更新された状態のレポからプルすることはできません)
  • フック/トリガー -- 品質 (タブは許可されないなど) フィルターを含むプッシュ/プルでの処理

ディレクトリ同期に .hg (または .git) ディレクトリの同期の維持を処理させるだけの場合、その同期中に、一貫性のない状態にあり、それを認識していないリモート ストアが得られます。

さらに、hg と git はどちらも、ディスク状態内でローカルのみのものとリモートで問題のないものを分離しています。彼らは、共有する情報 (例: コミットされた変更セット) と共有しない情報 (例: 現在のローカル作業ディレクトリの親リビジョン) を知っています。

他の回答では、人々は「おそらく大丈夫だろう」または「私は問題を抱えたことがない」と言っており、それはおそらく真実ですが、それが真実であるとは限りません。ソース管理システムには、適切で、より適切で、より安全で、より効率的で、より完全な機能を備えた同期プロトコルを使用してください。

于 2009-12-27T21:03:25.257 に答える
17

Dropboxのリポジトリが破損する問題が発生しました。常に発生するわけではありませんが、複数回発生しているということは、この目的でDropboxの使用をやめることを意味します。

とは言うものの、Dropboxは実際のホスティングを取得するよりも確かに安価であるため、バックアップを保持している限り、個人的なプロジェクトに受け入れられる可能性があります。

于 2010-02-11T14:18:28.337 に答える
10

1 台または 2 台のマシンでの個人的なプロジェクトではおそらく問題なく動作すると思いますが、実際には、複数メンバーのプロジェクトにはプロのホスティングを使用する必要があります。

私は個人的に BitBucket をしばらく使用してきましたが、非常に満足しています...無料アカウントでもプライベート プロジェクトを 1 つ持つことができます。

于 2009-12-26T21:11:05.633 に答える
2

同期の途中でリポジトリにアクセスしようとすると、問題が発生することが予想されます。また、オーバーヘッドも少しあるようです。同期するものを同期する必要はありません。ドロップボックスが競合をどのように処理するかはわかりませんが、scm を意識した方法で処理できるとは思えません。

于 2009-12-26T21:09:53.670 に答える
2

ビットバケットの場合は+1。それは無料で、その無料アカウントで 1 つのプライベート リポジトリを取得できます (github とは異なります)。

ドロップボックスのみのソリューションの欠点は、マシンのレポで何かを台無しにした場合、その失敗が bitbucket にコピーされ、ドロップボックスがインストールされている他のすべての場所に複製されることです。Dropbox は非常に高速であるため、問題を防ぐために時間内に停止することはできません。

リポジトリへの変更とそれらの変更の公開を切り離すことができなくなります。

私はドロップボックスを使用して、自宅と職場の両方のマシンで使用するいくつかのリポジトリをホストしていますが、これらのリポジトリの唯一のコピーではありません。また、bitbucket リポジトリ (およびそれらのクローンを持っている他の人々) もあります。

于 2009-12-27T03:37:54.107 に答える
2

私もHgでDropboxを使っていますが、今のところ問題はありません。遅すぎて、レポを実際に使用しようとした場合にのみ、定期的なチェックイン中に hg が破損を報告しないことに気付きました (本当に必要になるまで何かが壊れていることを知らないため、最悪の状況です)。

破損が自然発生的なものなのか、Mac、Windows、および Linux クライアントでリポジトリにアクセスしたことが原因なのかは明らかではありません (私は 3 つすべてを異なる時間に使用しています)。しかし、Mac だけがアクティブだったときに破損が発生したケースを少なくとも 1 件見たので、Dropbox 自体が原因である可能性があります。

危険な生活をすることにした場合は、「hg verify」（または「git verify」）を定期的に実行して、汚れを確認してください。

于 2011-03-04T11:50:30.163 に答える
1

Mac クライアントと Windows クライアントの間で競合するファイルがよく見られるため、mercurial で Dropbox を使用することはお勧めしません。特に undo が影響を受けますが、他のファイルとの競合も経験しました。

よろしくミルコ

于 2010-03-31T19:35:09.957 に答える
1

私はかなり長い間、個人的なプロジェクトのために git で Dropbox を使用してきましたが、まだ 1 つの問題も発生していません。ただし、Dropbox が同期するまで待たなければならない場合があります。同じプロジェクトで数人以上の人が作業している場合、これは小さな問題を引き起こす可能性があると思いますが、個人的なプロジェクトの場合、プッシュ/プルが高速であるという事実だけでも、GitHub よりも Dropbox の方が優れていることがわかります。

同期中のプッシュ/プルに関しては、これが問題を引き起こす可能性が高く、リポジトリが破損する可能性さえありますが、プロジェクトで作業しているのが 1 人だけである場合は、Dropbox がいつ同期するかを正確に知っています。

于 2009-12-27T14:37:14.880 に答える
0

bitbucket/github よりも Dropbox を使用することを好む人のために、クラウド バックアップ サービスの双方向同期プロセスによる破損を回避するために私が行っていることを次に示します。

私のローカル コード フォルダはc:\code& バックアップ フォルダはc:\Dropboxです。Dropbox フォルダー内には、truecryptで暗号化されたファイル コンテナーがあります (そのサイズは、私のコード フォルダーよりも十分に大きいです)。日中は、ローカルの Git/Mercurial リポジトリに定期的に変更をコミットしています。しかし、一日の終わりに、私は Dropbox を終了し、truecrypt ファイル コンテナーをマウントします。ファイル コンテナー内のベア リポジトリに変更をプッシュし、アンマウントして Dropbox を再起動します。

そうすれば、DVCS リポジトリのバックアップとして機能するクラウド サービスを安全に使用できます。ファイル コンテナが使用中の場合、Dropbox はアンマウントされるまで待機するので、破損に変化がないことを願っています。それでも、何らかの方法でファイル コンテナーの競合するコピーを取得した場合は、両方のコピーを簡単にマウントして変更セットを比較できます。

于 2013-07-03T19:28:07.343 に答える
0

現在、3台のマシンでBazaarで使用しています。ただし、私はどのブランチでも唯一の開発者です。

init-repo --no-trees コマンドを使用してリポジトリを作成しました。

于 2010-07-22T17:09:55.900 に答える