Subversionクライアントは、リポジトリの歴史的な変更をどのように処理しますか？

Question

私はSubversionリポジトリデータベースを変更する必要がありました。ダンプを作成し、リビジョンをフィルタリングして新しいデータベースを作成しました。

この新しいリポジトリは、すでにチェックアウトされている古いレポの作業コピークライアントと多くのコンテンツを共有しますが、間にリビジョンがありません。

削除されたリビジョンでデータが追加されず、一部のファイルのみが変更されました。

既存のクライアントにコピーを作成することなく、古いサーバーデータベースを新しいサーバーデータベースに置き換えることはできますか？あるいは、すべてのクライアントに新しいレポの新しいコピーをチェックアウトさせる必要がありますか？

もっと一般的には、サーバー側の構造の変更にSubversionクライアントがどのように対処しますか？私は主にTortoiseSVNに興味があります。

Answer 1

ダンプでリビジョン番号が変更されず、UUIDが保持されていれば、大きな違いはありません。 Subversionは、作業コピーファイルのリビジョン番号、リポジトリのUUIDとURLを追跡します。履歴が変更されても、作業コピーには影響しません。

非常にの場合、理論と事実には常に違いがあります。ダンプとロードを行う前に、開発者に事前に警告します。私は彼らにコードをチェックインさせる。次に、ダンプして読み込みを行い、開発者に清潔なチェックアウトを依頼します。

ちょうど安全であるように、きれいなチェックアウトをしてください。古い作業コピーでsvn statusを実行して、変更されたがコミットされていないファイルを見つけ出し、新しいクリーンチェックアウトにコピーすることができます。 svn statusはリポジトリに対してpingを実行しないため、安全な操作です。

Answer 2

壊れたチェックインで問題が発生しました。これは、レポから削除する必要がありました。作業が完了した後、私はいくつかのテストチェックインを実行したので、最新のリビジョン番号は他の開発者が持っていたものよりも少なくとも同じであった。私たちはこれを行うことに何の問題もなかった。

Answer 3

私の経験から、Tortoise SVNクライアント1.7は.svnディレクトリを着実に増やし、作業コピーの一番上で「クリーンアップ」を実行したときにのみ縮小します。

また、フィルタリングされたリビジョンのログメッセージ（およびその他の詳細）がすでにTSVNで見られた場合、この特定のキャッシュをクリアしない限り、GUIに表示されます。

別のリビジョン番号を含むリビジョン全体をフィルタリングして（次のリビジョンにフィルタされたリビジョンの番号があるように）古い作業コピーを保存しようとしません。

あなたの質問に直接答えるためのクライアントの内部について詳しくはわかりません。私も同様の状況にあったので、最初にサーバをテストすることをお勧めします。

• 実行新しい（フィルタリング）リポジトリの "svnadminのを確認し、"

さらにあなたのsvnadminは負荷（または負荷がsvnrdump）すでに持っている必要がありますが、歴史を行方不明につまずいた（ "デルタ"） 。

を新しいリポジトリから、すべての警告のために緊密にサーバーとお好みのクライアントを見ながら...

1. 精算少なくともファイル：しかし、私は、サーバーが実際に提供していること以上の証拠を収集することをお勧めこれらのファイルの上にあるディレクトリのフィルタリングと適切な対策のために影響されます。 （ディレクトリには他のファイルやサブディレクトリが含まれている必要はありません）
2. このチェックアウトは、フィルタリングされたものの1つ前のリビジョンに更新され、その後に1つのリビジョンが更新されます。
3. フィルタリングされたもし改訂番号がまだ残っていれば改訂番号
4. test（2.）はそれほど多くのファイルを改ざんしていない場合は改訂版に更新して、すべてのファイルを元の状態利用可能であれば、フィルタリングされたものの前後に別の変更の前後に適用される。歴史の「ギャップ」が問題を引き起こすかどうかを確認する。