7

私は git-svn ブリッジを使用しており、リポジトリ内の多数のファイルを再シャッフルしたので、少し整理されています。

git svn dcommit変更を SVN サーバーに戻すために実行したところ、プロセスがハングアップしたように見えます。dcommit過去 45 分間、通話にCPU もネットワークも使用されていません。出力は次の場所でスタックします。

> git svn dcommit
...snip...
     R       zlib/vs2005/zconf.h => tools/zlib/vs2005/zconf.h
     R       zlib/vs2005/zlib.h => tools/zlib/vs2005/zlib.h
     R       zlib/vs2005/zlib_ds.lib => tools/zlib/vs2005/zlib_ds.lib
     R       zlib/vs2005/zlib_ds.pdb => tools/zlib/vs2005/zlib_ds.pdb
     R       zlib/vs2005/zlib_s.lib => tools/zlib/vs2005/zlib_s.lib
     R       zlib/vs2005/zlib_s.pdb => tools/zlib/vs2005/zlib_s.pdb

そして、それは今約45分間続いている場所です。

編集: 最終的に、HTTPS 接続がタイムアウトしたと言って終了しました。これが起こるのに約1時間半かかりました。

dcommitこの呼び出しを中断するとどうなるか、ローカル リポジトリから SVN サーバーに変更を再送信する前に何をする必要があるかについて、決定的な情報が見つからないようです。

私の質問の一部に答えることができます: 再試行する前に何をする必要がありますか?

接続がタイムアウトし、プロンプトが返された後、再度実行するgit svn fetch前に実行する必要がありgit svn dcommitました。名前変更操作はすべて SVN リポジトリで見つかりましたが、シャッフル後に空のままだったディレクトリは削除されませんでした。それらを削除するには、SVN クライアントを使用する必要がありました。これが git-svn の問題なのか、それとも dcommit 呼び出し中の HTTPS タイムアウトによるものなのかはわかりません。

私はまだ答えを知りません: dcommit 呼び出しを中断することは安全ですか?

4

1 に答える 1

5

はい、安全です。

dcommit基本的に、SVN にプッシュするコミットごとにこれを行います。

  1. コミットとその親の違いを計算します。(基本的に、コミット用のパッチを作成します。)
  2. この差分を、SVN プロトコルを介して、コミットする変更セットとして送信します。これが完了すると、コミットが SVN サーバー上に存在するようになります。
  3. 新しいコミットと、その間に他のユーザーによって作成されたその他の新しいコミットを取得し、適切な Git コミットとしてローカルに保存します。git-svn ブランチ ref は、最新のものを指すように更新されます。
  4. コミットされている git-svn ブランチ ref に処理されたばかりのコミットの後に、すべてのコミットをリベースします。(処理中のコミットはサーバー上に存在する必要があるため、他のリベースと同様に、処理されたばかりのローカル コミットは破棄されます。)

ステップ 2 で中断すると (そのように聞こえます)、現在のコミットは svn サーバーで中止されます。心配することなく再度 dcommit できるはずです。

しかし、あなたが偏執的である場合 (そして、このように VCS 間で相互運用する場合はそうあるべきです)、git svn rebase最初に実行することをお勧めします。これにより、SVN 上の新しいコミット (実際にサーバー側で成功した場合は、プッシュしようとしたコミットを含む) がプルダウンされ、その上にローカル ブランチがリベースされます。

于 2010-11-16T03:53:02.220 に答える