svn - バージョン管理されているディレクトリをコピーする

Question

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

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

私は最近、SVNでそれを行うことについて同僚と話していました。大丈夫だと思いますが、SVNが作業コピーに正確に何を格納しているかわからないため、まだ100％確信はありません。

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

後で編集：

なぜ私がそうしたいのかと尋ねる人もいました。これが全体の話です：

SVNの場合、不在のためにSVNサーバーへの接続が非常に遅いため、私と同僚はソースを1回だけチェックして、ローカルコピーを作成することにしました。それは私たちがやったことであり、それはうまくいきました、しかし私はそれがうまくいくことが保証されているのか、それともちょうど起こったのか疑問に思っています。

bzrの場合、「メイン」リポジトリを別のサーバーに移動することを計画しています。そこで、そこにコピーして、メインレポを検討し始めることを考えていました。でも、一番安全なのはクローンを作ることだと思います。

Answer 1

In Subversion, every .svn folder has whatever is necessary for the containing folder. And since all local paths are stored as relative, you are safe while copying whole or partial trees outside the original checkout tree. They will continue to function in their new homes.

I frequently copy subtrees from my trunk outside, switch the new copies to other branches/tags and do whatever is necessary on the "cloned" local copies. This way, if, for any reason, I need to go back and do something in the trunk, I have an undisturbed trunk copy in the original location.

Copying source-controlled directories into other source-controlled trees, on the other hand, is unsafe. If you will be overwriting any .svn folders, you'll most probably be corrupting your target copies.

Answer 2

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

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

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

なぜコピーしなければならないのか知りたい人のために、私たちの大きなプロジェクトの1つを最初にチェックアウトするときに、ネットワークを介したチェックアウトが非常に遅いという問題がありました。対照的に、別のコンピューターからコピーするだけでも、同じメリットが得られるように見えました。

Answer 3

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

ただし、もう一度チェックアウトすることをお勧めします。.svnファイルなしでコピーが必要な場合は、svnexportが作成します。

Answer 4

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

Answer 5

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

しかし、おそらくあなたは「なぜ」を説明することができますか？

Answer 6

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

コピーはあなたの問題に対する最善の解決策ではないかもしれないので、あなたが何を達成しようとしているのか疑問に思います。

Answer 7

それはVCSに依存します。私はCVSで、バージョン管理されたすべてのディレクトリ内に（隠し）ディレクトリを格納することを知っています。もちろん、これらのファイルは、そのディレクトリの任意のコピーとともにコピーされます。

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

Answer 8

SVNの場合、これは一般的に他の人がすでに述べているように機能します。

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

安全を確保するために、新しい場所でチェックアウトするだけです。新しい作業ディレクトリに入れたい変更がコミットされていない場合（通常は悪い考えです）、rsyncを使用して、.svnディレクトリを導入せずにソースをコピーできます。

Answer 9

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

この修正で私が抱えている問題は、SVN が新しいファイルと見なすため、これらのファイルのバージョン トレイルが失われることです。また、以前のバージョンからの差分を保存することにより、ファイルの内容を効率的に保存しません。

SVN のドキュメントによると、svnクライアントがすべてのフォルダーの移動/作成/削除を実行できるようにして、次のコミットのためにすべてを同期させることをお勧めします。これは、Visual Studio から常に受け入れられるとは限りません。幸いなことに、特に TortoiseSVN を使用している場合、ほとんどの問題はコミット時に発見されます。

Answer 10

切断されている、または接続が不安定であるとおっしゃっているように、GITもニーズに対応しているように思えます。GITは非常に優れたSVNサポートも備えているため、この2つは補完的であり、最終的には優れたバージョンのファイルシステムになります。