2

私はかなり大きなプロジェクト（13 GB）を持っていて、インターネット接続が貧弱です。作業ディレクトリのコピーをフラッシュドライブに持ち帰りましたが、サイズが2倍になる.svnディレクトリがありませんでした。

フラッシュドライブの内容をコピーして、適切な作業ディレクトリに変換したいと思っていました。 基本的にチェックアウトですが、フラッシュドライブから提供される13GBのファイルを使用します。

  • このアイデアhttps://stackoverflow.com/a/861020/826062は、フラッシュドライブファイルを新しいローカルリポジトリにインポートし、そのリポジトリをチェックアウトしてから、sw--そのチェックアウトをオンラインリポジトリに再配置することです。これには、ローカルリポジトリのUUIDを設定する必要があることに注意してください。設定しないと、SVNが停止します。

この巧妙なアイデアは、さまざまな理由で機能しません（E155017：チェックサムの不一致または「邪魔な作業コピーが見つかりました」）。

  • 私の次のアイデアは、チェックアウトの空のツリーを作成し（接続を介して行うのが安価）、ファイルをそのツリーにrsyncすることでした。SVNはこれを行うことにそれほど関心がありません（深さを無限大に復元する際のさまざまな問題）。

これらのアイデア/実験の多くを使用して、SVNは接続を介してすべてを再度ダウンロードしようとします（おそらく、ローカルとリモートを比較するためのチェックサムができないためですか？）

長い説明で申し訳ありませんが、全体像としては必要だと思います。

他の誰かがコピーされたローカルファイルを既存のSVNリポジトリと同期させようとしますか？

4

2 に答える 2

5

この.svnディレクトリには、バージョン管理された各ソースファイルの「クリーンな」コピーが含まれているため、ディレクトリが非常に大きくなります。ただし、メタデータも含まれているため、再構築が非常に困難です。

対照的に、作業ファイルは、のクリーンコピーから簡単に再構築できます.svn。したがって、別のアプローチは、ディレクトリのみをコピーしてから、ネットワークトラフィックなしで作業ファイルを復元するために実行することです。.svnsvn revert -R .

于 2013-02-01T09:27:01.513 に答える
2

.svn残念ながら、ディレクトリのない作業コピーは、作業コピーではありません。テキストベース（またはSubversion 1.7以降で呼び出されている元のテキスト）のコピーを回避できる場合もありますが、.svnディレクトリを完全に無視することはできません。

いくつかの可能な救済策：

DVCSはコピーに対していくらか回復力があるため、切断された作業コピーを持つためのメカニズムとしていくつかのDVCSを使用してみることをお勧めします。git-svn頭に浮かぶ。

作業中のコピーをフラッシュドライブ上のファイルにtarで保存してから、自宅のディスクに解凍することもできます。

于 2013-01-28T00:30:39.920 に答える