0

次のコマンドが着信競合を報告するという奇妙な問題がリポジトリに表示されています。

svn merge --dry-run -r BASE:HEAD . | egrep -e '^[[:space:]]*(A|B|C|D|E|G|U)+[[:space:]]+'

   C path/to/fileA
   C path/to/fileB
   C path/to/fileC
U    path/to/fileD

ただし、svnupは実際には競合を引き起こしません。実際、出力は次のようになります。

At revision 7922.
At revision 7922.
At revision 7922.
U    path/to/fileD
Updated to revision 7922.

私の知る限り、問題のファイルについては何も奇妙なことはありません。svnステータスは問題を報告せず、svn infoはファイルが最新であることを示し、svnresolveは効果がありません。これは定期的に発生しますが、毎回発生するわけではなく、常に同じファイルが表示されます。

誰かがこれを見たことがありますか？

編集：私は重要な詳細を省略したようです。それがおそらく誰もここで答えることができなかった理由です。svn upステップでは、段階的な自動展開中の衝突を回避するために、各ファイルを個別に更新しています（たとえば、t0：着信更新を先読みする、t1：データベースに対して必要なスキーマ変更を実行する、t1 + X：残りの部分を更新するバッチ。Xは自明でない数値である可能性があります）。完全な更新は次のようになります。

svn up --depth=empty path/to/fileA path/to/fileB path/to/fileC path/to/fileD

At revision 7922.
At revision 7922.
At revision 7922.
U    path/to/fileD
Updated to revision 7922.
4

1 に答える 1

0

ここでの問題は、同期していない親ディレクトリに起因しているようです。

元：

リビジョンX：

A  path/to/fileA

リビジョンX+1：

A  path/to/fileB
A  path/to/fileC

私たちはそのように更新していました:(BASE=X-1およびHEAD=X + 1と仮定しましょう）

%> cd dir/
%> svn merge --dry-run -r BASE:HEAD .     # look ahead for incoming updates
%> ...                                    # run schema updates against DB
%> svn up --depth=empty path/to/fileA     # update just the incoming changes to
   path/to/fileB path/to/fileC            # avoid pulling someone else's
                                          # recent commit

これは、コミットに関係する3つのファイルにとってはすべて問題ありませんが、dir /、dir / path /、およびdir / path /to/はHEADリビジョンの背後にあります。svn info dir /は、以前のsvn upに含まれていなかったため、リビジョンをX-1（BASE）として報告します。

リビジョンX+2に到達すると、次のようになります。

U  path/to/fileD

プロセスを再試行しますが、今回は先読みレポートで競合が発生します。

%> cd dir/
%> svn merge --dry-run -r BASE:HEAD .
...
   C path/to/fileA
   C path/to/fileB
   C path/to/fileC
U    path/to/fileD
...

（実際にファイルがすでに存在する場合、着信はX-1-> X + 2から追加されます）。同時に、これらのファイルのsvn upは、すべてが最新であることを無害に報告します。

その後、デプロイメントをよりアトミックなプロセスに変えたので、ブランチルートからすべてを自由に起動し、醜い--depth = emptyを回避し、すべてのファイルの同期を維持できます。

于 2012-10-23T01:43:48.800 に答える