3

「ダム」ファイルサーバーに変更を公開し、反対側でそれらを再アセンブルすることにより、リポジトリをミラーリングすることは可能ですか (SVN、Git、Hg などを選択)。

プロセスの図

考えられる懸念には次のものがあります。

  • 移動・改名・削除されたファイルの扱い
  • バイナリ ファイル
  • 空のディレクトリ

たとえば、svn diff > r1.patchSVN はそれらを含めるように設計されていないため、バイナリ ファイルを失うことを意味することを理解しています。

注: これは、帯域幅を最小限に抑えようとしているため、(リポジトリ ファイル全体をアップロードせずにそれを行う方法がない限り) ファイル サーバーにリポジトリを配置することにはなりません。また、リポジトリの代わりに差分を保存するということは、暗号化が可能であることを意味します。

4

4 に答える 4

3

はい、可能です

転覆

  • リビジョン N ( svn diff -c N --git PATH > PATCH.N) から git-patch を作成します。
  • パッチを保存します。
  • 別の面にパッチを適用します ( svn patch PATCH.N <WCPATH>)。

マーキュリアル

単一チェンジセット交換(マージセットにも悪い)

  • 変更セット N を patch ( hg export -g -r N -o %b-%r.patch) としてエクスポートします (1 つのディレクトリにマルチリポジトリ ストレージがある場合は、ファイル名を -o に指定)。
  • パッチを保存します。
  • 別の面にパッチを適用します ( hg import --exact -s 100 FILENAME.patch)。

レンジセット交換

バンドル

  • バンドル範囲 N:M ( hg bundle --base parent(N) --rev N::M N-M.hg);
  • パッチを保存します。
  • 別の面にパッチを適用します ( hg unbundle -u N-M.hg)。

書き出す

  • 範囲セット N:M をパッチとしてエクスポート ( hg export -o %b-%r.patch -r N::M) (ファイル名が「repobasebame-revno.patch」のパッチのセット);
  • パッチを保存します。
  • 結果として反対側にパッチを適用します (最小から最大)。
于 2013-01-23T05:28:24.270 に答える
2

コマンドgitがあるからです。bundle指定されたリビジョンのバイナリ アーカイブを作成します。履歴の一部をコミットごとに、またはまとめてバンドルに入れ、ファイル サーバーにコピーしてから、リポジトリに復元することができます。

git bundle create file.name revisions..list— バンドルを作成するためのコマンド。

git bundle unbundle file.name— リビジョンを復元するコマンド。

間違いなく、バンドルを混同しないように年代順に名前を付ける必要があります。

それは機能しgit、私が覚えている限り、コマンドもhg備えています。bundleこれはあなたがそれを描くときのアプローチです。

もう 1 つの方法initは、Dropbox フォルダに新しい中間リポジトリを作成し、そこにメイン リポジトリからコミットをプッシュして、Dropbox にミラーと同期させることです。ただし、この場合、ミラー リポジトリへのプルは、Dropbox の同期が完了した後でのみ行う必要があります。そうしないと、git が大量の小さなファイルを使用してリポジトリのコンテンツを保持するため、データの一貫性が失われる可能性があります。リポジトリのコンテンツをパックすることで、このような動作を回避することができます。しかし、安全を期すなら、バンドルアプローチが最適です...

編集：svn最近、別の手がかりを得ました。標準のバックアップ アプローチを使用して必要なものを達成できる場合、この Q&A で説明されている標準のバックアップ アプローチを試す理由gitは何ですか?hgsvn

svnadmin dump repositorypath -r LO_REV:HI_REV > backupname.svnリビジョンをバックアップします。

svnadmin load repositorypath < backupname.svnデータを復元します。

于 2013-01-18T15:46:56.627 に答える
0

github のようなリポジトリ ホスティング サービスを使用していない理由はありますか? git は diff のみをプッシュするため、帯域幅が最小限に抑えられます。

于 2013-01-22T11:10:06.257 に答える
0

git は、必要な差分を送信するだけで十分に機能するため、これはまったく必要ありません。mercurial (hg) も同じです。bzr がそうでなかったとしたら、私は非常に驚くでしょう。svn や cvs のような集中化された VCS は、明らかにそうではありません。他の制限がある場合にのみ、ファイルサーバーへの発送が意味をなします (もしそうなら、本当に役立つことができるようにするためには、それらについて知る必要があります)。

rsync(1) を使用してリポジトリをコピーすることもできますが、その場合、半分更新されたものを誰も見ないことを保証する VCS を期待することはできません。そのようなことを行う場合は、細心の注意を払ってください。一般に (bzr を除く)、たとえば、リポジトリを別の場所でバックアップおよび復元するだけで、問題なく動作するはずです。

いずれにせよ、ビットが欠けている色付きの四角形の後ろに隠れている誰かがあなたに言うことを盲目的に信じないでください...自分で確認し、ドキュメントを読み、推奨されるプラクティスを探し、少し実験してください.

于 2013-01-23T01:07:39.343 に答える