バージョン管理されたディレクトリのコピー

StackOverflow https://stackoverflow.com/questions/56657

質問

バージョン管理下にあるディレクトリをコピーして、両方のコピーで作業を開始してもよいかどうか知りたいです。

VCS ごとに異なる可能性があることはわかっていますが、さまざまなケースに興味があるため、意図的に VCS を指定しません。

最近、SVN でそれを行うことについて同僚と話していました。これで問題ないと思いますが、SVN が作業コピーに正確に何を保存しているのかがわからないため、まだ 100% 確信は持てません。

ただし、DVCS の世界について話す場合、すべての作業コピーはそれ自体がリポジトリであるため、状況はさらに不明確になる可能性があります。今、bzr でこれを行うことに直面しているので、質問することにしました。

後で編集:

なぜそんなことをしたいのかと尋ねる人もいました。ストーリー全体は次のとおりです。

SVN の場合は、外出中のため SVN サーバーへの接続が非常に遅かったため、私と同僚はソースを 1 回だけチェックアウトしてローカル コピーを作成することにしました。私たちはそれを実行し、問題なく動作しましたが、動作が保証されているのか、それともたまたまそうなったのかはまだ疑問です。

bzr の場合、「メイン」リポジトリを別のサーバーに移動する予定です。そこで、それをそこにコピーして、それをメインのリポジトリとして検討し始めることを考えていました。ただし、クローンを作成するのが最も安全だと思います。

役に立ちましたか？

解決

Subversion では、各 .svn フォルダーには、そのフォルダーに必要なものがすべて含まれています。また、すべてのローカル パスは相対パスとして保存されるため、元のチェックアウト ツリーの外側にツリー全体または部分をコピーしても安全です。彼らは新しい家で引き続き活動していきます。

私は頻繁に屋外のトランクからサブツリーをコピーし、新しいコピーを他のブランチ/タグに切り替え、「クローン」ローカル コピーで必要なことはすべて行います。こうすることで、何らかの理由でトランクに戻って何かをする必要がある場合でも、元の場所に元の場所にそのままのトランク コピーが保存されます。

ソース管理されたディレクトリのコピー の中へ 一方、他のソース管理ツリーは 危険な. 。.svn フォルダーを上書きする場合は、ターゲットのコピーが破損する可能性があります。

他のヒント

私はSVNでこれを時々実行しますが、問題は発生していません。SVN に保存されるのは、ディレクトリの元の状態と、その元のリポジトリ ディレクトリへのポインタだけだと思います。

したがって、基本的には思ったとおりに機能します。

  • Copy1 の File1 が変更され、Copy2 の File2 が変更された場合、両方ともコミットできます
  • Copy1 の File1 が変更され、Copy2 の File1 が変更された場合、2 番目にコミットした人にエラーが発生し、最初に更新/マージする必要があります。

なぜコピーしなければならなかったのか知りたい人のために言っておきますが、大規模なプロジェクトの 1 つを初めてチェックアウトするときに、ネットワーク経由でのチェックアウトが非常に遅いという問題が発生しました。対照的に、別のコンピュータからコピーするだけでも、まったく同じメリットが得られるように思えました。

svnでは問題ありません。2 回目のチェックアウトを行ったかのように、そのコピーを操作するだけです。

ただし、もう一度チェックアウトすることをお勧めします。.svn ファイルを含まないコピーが必要な場合は、svn export によってコピーが作成されます。

bzr の場合は、.bzr ディレクトリを別の場所にコピーするだけで機能します。パスやホストに関する情報は保存されないため、どこにでもコピーして問題なく動作することが期待できます。

ソース管理メカニズムを回避しているので、やめることをお勧めします。

しかし、おそらく「なぜ」を説明できるでしょうか？

また、(少なくとも SVN を使用して) 2 つの作業コピーを work/copy1 と work/copy2 としてチェックアウトし、2 つのバージョンを並行して作業することもできます。

コピーすることが問題の最良の解決策ではない可能性があるため、何を達成しようとしているのか疑問に思います。

VCS によって異なります。CVS では、バージョン管理されたすべてのディレクトリ内に (隠し) ディレクトリが保存されることがわかっています。もちろん、これらのファイルは、そのディレクトリのコピーとともにコピーされます。

これらの隠しファイルをコピーしたくない場合が非常に多いため、rsync ツールには CVS と同じようにこれらのファイルを無視するオプション (-C) が付属しています。

Visual Studio 内からフォルダー レイアウトを再編成するときに、SVN に関していくつかの頭痛が発生しました。ソリューション内でフォルダーを移動すると、文字通り、隠しフォルダーも含めてファイル システム内のフォルダーが移動されます。 .svn フォルダ。これによりコミットの問題が発生します。 .svn データは古いパスに関連付けられていますが、新しいパスに再度関連付ける方法が見つかりません。SVN clean up 正常に実行されますが、何も修正されません。SVN switch フォルダーを移動した後は変更できません。すべて削除することでのみこれを修正できました .svn 移動したフォルダー内のフォルダーとそのサブフォルダーを削除し、フォルダーを再度追加します。

この修正に関して私が抱えている問題は、SVN がファイルを新しいものとして認識するため、これらのファイルのバージョン証跡が失われることです。また、以前のバージョンとの差分を保存するため、ファイルの内容が効率的に保存されません。

SVN ドキュメントによれば、 svn クライアントはフォルダーの移動/作成/削除をすべて実行して、次のコミットに備えてすべての同期を維持します。これは Visual Studio から常に受け入れられるわけではありません。幸いなことに、特に TortoiseSVN を使用している場合、ほとんどの問題ケースはコミット時に検出されます。

SVN の場合、他の人がすでに述べたように、これは通常機能します。

ただし、マシン間でコピーしている場合は、おそらく問題が発生するでしょう。たとえば、file:// リポジトリ URL を使用して SVN リポジトリにアクセスしている場合、問題が発生する可能性が高くなります。サーバーアクセスが異なる可能性がある http:// または svn:// URL にも同じことが当てはまります。

安全を確保するために、新しい場所でチェックアウトするだけです。コミットされていない変更が多数あり、それを新しい作業ディレクトリに保存したい場合 (通常は悪い考えです)、rsync を使用して、.svn ディレクトリを取り込まずにソースをコピーすることができます。

切断されている、または接続が不安定であると述べているように、GIT もニーズを満たす可能性があるように思えます。GIT は非常に優れた SVN サポートも備えているため、この 2 つは補完的であり、最終的には優れたバージョン管理されたファイル システムが得られます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top