Archivos .r aleatorios creados al usar Jenkins y SVN

Tengo un sistema de compilation automatizado de mi proyecto de Android usando Jenkins que se sincroniza a través de SVN. De vez en cuando obtengo nuevos files agregados al espacio de trabajo que, supongo, proceden del process SVN que son colisiones. Cuando esto ocurre en la carpeta de resources, provoca un error de compilation, ya que las extensiones de file se eliminan y hay una colisión en el espacio de nombres.

p.ej

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

¿Alguna idea de por qué estoy recibiendo estos files r584, r588? Probablemente lo más importante, ¿cómo evito que esto suceda?

Mientras que la compilation de jenkins es local para la máquina, el directory SVN original en el que trabajo está dentro de una carpeta administrada de Dropbox (¡no preguntes!). Aunque no creo que esto sea un problema, creo que debería mencionarlo solo en caso de que tenga un factor contribuyente.

Estos .r ??? Los files no existen en mi tree fuente original o en la estructura SVN, por lo que solo puedo realizarlos con la operación de synchronization de SVN realizada por Jenkins hasta donde yo pueda ver.

Como han dicho otros, * .rNNN son conflictos de fusión SVN, donde NNN es el número de revisión que está en conflicto. De nuevo, como han dicho otros, Jenkins debe ser el propietario del espacio de trabajo, no otra cosa.

Déjame tratar de aclarar algo aquí. Usted dijo "the original SVN directory I work in is inside a dropbox managed folder (don't ask!)." . Estas diciendo eso:

a) Está utilizando un espacio de trabajo personalizado para Jenkins (habría tenido que perder el time con las configuraciones de espacio de trabajo personalizadas para eso)
b) Su directory de trabajo (del usuario) es una carpeta administrada de Dropbox

Si b) es cierto, está bien. Pero si a) es cierto, esto puede causar todo tipo de problemas. Si este es el caso, realmente necesita dejar que Jenkins administre su propio espacio de trabajo. Sí, eso puede significar el doble de requisitos de espacio, pero esta es la forma en que debería ser.

Ahora, suponiendo que Jenkins administre el espacio de trabajo de Jenkins, lo primero que intentará hacer es SVN Update . Esto nunca debería causar problemas de combinación (esos files * .rNNN), a less que algo esté modificando el espacio de trabajo. Nuevamente, si el punto a) es verdadero, considere darle a Jenkins su propio espacio de trabajo. La construcción en sí podría estar modificando el espacio de trabajo (no estoy familiarizado con las comstackciones de Android o lo que hace con los files).

En cualquier caso, lo que quiere es hacer una verificación limpia de SVN. Hay dos opciones que funcionarán para usted.

  • Siempre mira una copy nueva
  • Usar svn update es tanto como sea posible con 'svn revert' antes de la actualización

Ambos se encuentran en la configuration del trabajo, en "Gestión de código fuente", en "Estrategia de pago".

El primero limpiará el espacio de trabajo de Jenkins y realizará un pago completo. Esto puede ser más largo, pero "más limpio".

El segundo intentará revertir cualquier cambio local en el área de trabajo antes de hacer una actualización de SVN, eliminando así los conflictos de fusión.

se ven como marcadores de conflicto: cuando se fusiona, si no puede resolver automáticamente el problema, colocará 2 files temporales en el directory con los numbers de revisión como parte de la extensión del file. Se supone que debes usar una aplicación de diferencias para decidir cómo debería ser el file final y luego decirle a svn que has resuelto el conflicto. SVN luego eliminará los viejos files temporales y le permitirá confirmar su cambio.

Tus compromisos tendrán desperdicio en ellos hoy; si miras el file del mismo nombre, verás marcadores de diferencias embeddeds en el código fuente. Me sorprende que pueda comprometerse en absoluto, pero supongo que la copy del dropbox está afectando la situación de alguna manera: ¿está cometiendo deltas o simplemente está revisando el directory como si se tratara de un grupo de files nuevos?

AFAIK, los files * .r ### son, como sugiere, cuando hay un conflicto con lo que se está revisando. (Traté de encontrar una buena reference y no lo hice. Aunque los he visto a mí mismo).

Dado que esto generalmente ocurre cuando hay un conflicto al momento de pagar, hay un par de cosas que consideraría para resolver el problema.

  1. Asegúrese de que los files que se están revisando en su espacio de trabajo de Jenkins no se estén modificando. Si se supone que deben ser modificados por el process, es posible que desee ver esta respuesta para forzar la extracción de SVN para sobrescribir .
  2. Compruebe los permissions del directory frente al del usuario con el que se está ejecutando Jenkins.

En general, Jenkins debe ser el propietario y el único manipulador del espacio de trabajo para cualquier trabajo que esté ejecutando.