Home/ Questions/Q 9176313
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T17:05:03+00:00

I’ve got an automated build system from my Android project using Jenkins which syncs

  • 0

I’ve got an automated build system from my Android project using Jenkins which syncs via SVN.
Occasionally I get new files added to the workspace which I assume are from the SVN process that are collisions. When this happens in the resource folder it causes a build failure as the file extensions are stripped and there is a name space collision.

e.g. 

 [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.

Any ideas why I’m getting these r584, r588 files? Probably more importantly, how do I stop this from happening?

Whilst the jenkins build is local to the machine, the original SVN directory I work in is inside a dropbox managed folder (don’t ask!). Whilst I don’t think this is a problem I feel I should mention it just in case it does have a contributing factor.

These .r??? files don’t exist in my original source tree or SVN structure so can only be made by the SVN syncing operation done by Jenkins as far as I can see.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Like others have said, *.rNNN are SVN merge conflicts, where NNN is the revision number that is in conflict. Again, like others have said, Jenkins must be the owner of the workspace, not something else.

    Let me just try to clarify something here. You said "the original SVN directory I work in is inside a dropbox managed folder (don't ask!).". Are you saying that:

    a) You are using a custom workspace for Jenkins (you would have had to muck around with custom workspace settings for that)
    b) Your (user’s) working directory is a dropbox managed folder

    If b) is true, that’s OK. But if a) is true, this may cause all sorts of problems. If this is the case, you really need to let Jenkins manage its own workspace. Yes, that may mean double the space-requirements, but this is the way it should be.

    Now, assuming that Jenkins’s workspace is managed by Jenkins, the first thing it will try to do is SVN Update. This should never cause merge problems (those *.rNNN files), unless something is modifying the workspace. Again, if point a) is true, consider giving Jenkins it’s own workspace. The build itself could be modifying the workspace (I am not familiar with Android builds or what it does with files).

    In either case, what you want is to do a clean SVN checkout. There are two options that will work for you.

    • Always check out a fresh copy
    • Use svn update is much as possible with ‘svn revert’ before update

    Both of these are found in the job configuration, under “Source Code Management”, under “Check-out Strategy”.

    The first will clean the Jenkins workspace and do a full checkout. This may be longer, but “cleaner”.

    The second will try to revert any local changes to the workspace before doing an SVN update, thus eliminating the merge conflicts.

    • 0