svn-copyで作成されたSVNブランチを更新する方法は？
noobの質問は知っていますが、見つけたすべてのリソースが失敗するか、新しい問題が発生しました。
SVNリポジトリにいくつかのブランチがあります。すべての開発者は彼の個人ブランチにアクセスできます。各ブランチは、ベータブランチからのコピーによって作成されました。
svn copy svn://192.168.0.2/svn/example/branches/beta
svn://192.168.0.2/svn/example/branches/dev/devN
Dev1が機能するようになったら、彼はベータ版で自分の作業をマージします（pwd = ./beta/）
svn merge svn://192.168.0.2/svn/example/branches/dev/dev1@4242 .
さて、私の質問は、他の開発者がdev1の変更でどのようにして自分のブランチを最新のベータ版に更新できるのかということです。
dev2がマージを行うとき（彼自身の変更をコミットした後| pwd = ./dev/dev2）
svn merge svn://192.168.0.2/svn/example/branches/beta@4242 .
彼はこのメッセージを受け取ります：
svn: E195016: Merge tracking not allowed with missing subtrees; try restoring these items first:
pointing his files. -> impossible to merge.
ブランチのコピーを「更新」する方法はありますか？
このエラーメッセージは、誰かがSubversionに通知せずに何かを削除したときに発生します。その作業コピーでsvn statusを実行した場合、Subversionが不平を言っているのと同じパスが、出力の最初の列に!と表示されます。これは通常、誰かがsvnコマンドではなくOSコマンドを使用してパスを削除したことを意味します。
パスを本当に削除したい場合は、svn rmコマンドを使用してこれをSubversionに通知することで修正できます。パスは、ステータス出力の最初の列にDが付いた削除済みとして表示され、マージが続行されます（ツリーの競合が発生する可能性があります）。
詳細については、このエラーメッセージが追加された理由を説明するSubversionプロジェクトの issue＃2915 を参照してください。
Windowsで作業していて、パスが256文字を超える場合、Windowsは物事に不快になり始めます。私は通常、ルートファイルシステムの短いディレクトリ（C：\ WRKなど）の直下にワークスペースを作成してこれを回避します。これは、C：\ Users\user_name\Desktop \ディレクトリよりはるかに短いパスを使用します。ワークスペースを作成したら、簡単にアクセスできるようにデスクトップにショートカットを追加します。
このエラーが発生し、TortoiseSVNでチェックアウトしたところです。何も削除されていません。長いパスの最後に、「共通」ディレクトリが作成されていることがわかりました。これは、Repo-broswerにアクセスしても表示されません。親ディレクトリを削除して更新すると、「common」ディレクトリが再び表示されます。親ディレクトリには赤いXも表示されます。これは、TortoiseSVNがSVN削除コマンドではなく、OSコマンドを介して何かが削除されたと考えていることを示します。
コードのどこかにバグがあると思います。パスの長さと関係があるのか（Windows 7の問題ですか）、それとも他に問題があるのかわかりません。
同じメッセージがありました。 svn statusは、1つのファイルに！があると言っていました。それは私のファイルシステムにありました、svnはそれをデータベースに持っていましたが、svnはそれが削除されたと考えました（そうではありませんでした）。私はそれを削除し、Subversion経由で削除し、svn statusがOKでファイルが本当に見つからなくなるまですべてをコミットしなければなりませんでした。その後、謎のファイルを元の場所にコピーして追加し、再度コミットしました。その後、Subversionとファイルシステムがバック同期されました。これはSubversionのエラーであったに違いありません。しかし、幸いにも私はそれを修正することができました。