1

SVN 経由で同期する Jenkins を使用して、Android プロジェクトから自動ビルド システムを取得しました。時折、コリジョンである SVN プロセスからのものと思われる新しいファイルがワークスペースに追加されます。これがリソース フォルダーで発生すると、ファイル拡張子が取り除かれ、名前空間の競合が発生するため、ビルド エラーが発生します。

例えば

 [aapt] res\drawable\icon.png.r584:0: error: Resource entry icon is already defined.
 [aapt] res\drawable\icon.png:0: Originally defined here.
 [aapt] res\drawable\icon.png.r588:0: error: Resource entry icon is already defined.
 [aapt] res\drawable\icon.png:0: Originally defined here.

これらのr584、r588ファイルを取得する理由はありますか? おそらくもっと重要なことですが、どうすればこれが起こらないようにできますか?

jenkins ビルドはマシンに対してローカルですが、私が作業する元の SVN ディレクトリはドロップボックス管理フォルダー内にあります (聞かないでください!)。これは問題ではないと思いますが、要因がある場合に備えて言及する必要があると思います.

これらの.r??? ファイルは元のソース ツリーまたは SVN 構造に存在しないため、私が見る限り、Jenkins によって実行される SVN 同期操作によってのみ作成できます。

4

3 に答える 3

3

それらは競合マーカーのように見えます-マージするときに問題を自動的に解決できない場合は、ファイル拡張子の一部としてリビジョン番号を含む2つの一時ファイルがディレクトリに配置されます。diffアプリを使用して、最終的なファイルがどのように表示されるかを決定し、競合を解決したことをsvnに通知することになっています。その後、SVNは古い一時ファイルを削除し、変更をコミットできるようにします。

今日のコミットにはゴミが含まれています。同じ名前のファイルを見ると、ソースにdiffマーカーが埋め込まれているのがわかります。コミットできることに驚いていますが、ドロップボックスのコピーが何らかの形で状況に影響を与えていると思います。デルタをコミットしているのですか、それとも新しいファイルの束であるかのようにディレクトリをチェックインしているだけですか。

于 2013-01-21T12:56:38.450 に答える
2

他の人が言ったように、 *.rNNN は SVN マージの競合です。NNN は競合しているリビジョン番号です。繰り返しますが、他の人が言ったように、Jenkins はワークスペースの所有者でなければなりません。

ここで何かを明確にしてみましょう。あなたは言っ"the original SVN directory I work in is inside a dropbox managed folder (don't ask!)."た。あなたはそれを言っています：

a) Jenkins のカスタム ワークスペースを使用している (カスタム ワークスペース設定をいじる必要があった)
b) (ユーザーの) 作業ディレクトリがドロップボックス管理フォルダーである

b) が true の場合、それで問題ありません。しかし、a) が true の場合、これはあらゆる種類の問題を引き起こす可能性があります。この場合、Jenkins に独自のワークスペースを管理させる必要があります。はい、それはスペース要件が2倍になることを意味するかもしれませんが、これはあるべき姿です。

ここで、Jenkins のワークスペースが Jenkins によって管理されていると仮定すると、Jenkins が最初に行うことはSVN Update. ワークスペースが変更されていない限り、これによってマージの問題 (これらの *.rNNN ファイル) が発生することはありません。繰り返しますが、a) が当てはまる場合は、Jenkins に独自のワークスペースを与えることを検討してください。ビルド自体がワークスペースを変更している可能性があります (私は Android ビルドや、それがファイルに対して行うことについてよく知りません)。

どちらの場合でも、クリーンな SVN チェックアウトを実行する必要があります。あなたのために働く2つのオプションがあります。

  • 常に新しいコピーをチェックアウト
  • 更新前に「svn revert」を使用すると、svn update を使用できます

これらは両方とも、「ソースコード管理」の下の「チェックアウト戦略」の下のジョブ構成にあります。

1 つ目は、Jenkins ワークスペースをクリーンアップし、完全なチェックアウトを行います。これは長くなる可能性がありますが、「よりクリーン」です。

2 つ目は、SVN の更新を行う前にローカルの変更をワークスペースに戻そうとするため、マージの競合が解消されます。

于 2013-01-21T15:54:56.463 に答える
1

私の知る限り、 *.r### ファイルは、あなたが示唆するように、チェックアウトされているものと競合する場合です。（私は良い参考文献を見つけようとしましたが、見つけられませんでした。しかし、私はそれらを自分で見ました。）

これらは通常、チェックアウト時に競合が発生したときに発生するため、問題を解決するためにいくつか確認することがあります。

  1. Jenkins ワークスペースでチェックアウトされているファイルが変更されていないことを確認してください。それらがプロセスによって変更されることが想定されている場合は、 Force SVN checkout to overwriteに対するこの回答を確認することをお勧めします。
  2. ディレクトリのアクセス許可と、Jenkins が実行されているユーザーのアクセス許可を確認します。

一般に、Jenkins は、実行中のジョブのワークスペースの所有者であり、唯一のマニピュレーターである必要があります。

于 2013-01-21T12:57:20.410 に答える