Se funde en los files IntelliJ IDEA .IPR y .IWS

Mantenemos nuestros files IntelliJ .IPR e .IWS en nuestro control de fuente, pero IntelliJ los sigue modificando con solo abrirlos, incluso sin realizar ningún trabajo en el proyecto.

¿Qué estamos haciendo mal?

"Conservamos nuestros files IntelliJ .IPR e .IWS en nuestro control de fuente, pero IntelliJ los sigue modificando simplemente abriéndolos, incluso sin que se haya realizado ningún trabajo en el proyecto".

El file .IWS es definitivamente un file por desarrollador, por lo que no debe estar bajo control de fuente.

En cuanto al file .IPR en un proyecto reciente, inicialmente intentamos versionar este file acercándolo conceptualmente como lo haría con un proyecto .Net y el file VS.Net .SLN. Nuestro objective era conseguir que un desarrollador se ejecutara en una PC limpia en 15 minutos, incluido el time que lleva instalar un software dependiente como el IDE o una database local. Al final nos acercamos un time para modificar la configuration local como se muestra a continuación.

El problema es que el file .IPR almacena más configuraciones que un file .sln -eg configuraciones para complementos individuales. Entonces, una de las principales causas de sobrescritura es que si un desarrollador con una configuration de complemento diferente abre el file IPR, algunas configuraciones pnetworkingeterminadas para el complemento se escriben en el file. Sentimos que los desarrolladores no deberían tener que limitarse a un superset de plugin dado (solo una configuration mínima).

La forma en que alivió el problema (aunque no se resolvió del todo) fue cambiar al formatting de carpeta .idea. Esto toma el contenido del file .IPR y divide muchos de los nodos en files y carpetas individuales en la subcarpeta .idea. Desde aquí, pudimos excluir muchos de los files escritos frecuentemente en el control de origen. Algunos de los files que excluimos fueron:

  • workspace.xml
  • dataSources.xml
  • sqlDataSources.xml
  • dynamic.xml

Algunos files que nos gustaría que IntelliJ deje en paz son (aunque la culpa también puede ser para los desarrolladores de complementos y no solo para Jetbrains):

  • projectCodeStyle.xml (para que podamos get un formatting de código coherente en el proyecto; una vez más, esto puede sobrescribirse en function de la combinación de complementos locales de un desarrollador).
  • cualquier file en la carpeta runConfigurations. Puede llevar mucho time configurar configuraciones de ejecución, especialmente si tiene una aplicación compleja con muchas facetas. La cosa más comúnmente estúpida que se modifica simplemente abriendo el IDE o la construcción es la opción "DEBUG_PORT" en RunnerSettings. Mi opinión es si se asigna dinámicamente ¿por qué no tener un valor de "Dinámico"?
  • misc.xml. Este file también contiene configuration de complemento. Algunas configuraciones parecen prácticas para compartir y otras buscan más configuraciones personales. Por ejemplo, el complemento IvyIDEA pone una ruta absoluta a su file de configuration ivy.
  • Los files del module. En su mayoría, se los deja solos, pero un ejemplo de sobrescritura innecesaria es el complemento IvyIDEA que incluye detalles de la location del caching ivy local en este file. Pero de nuevo, esto es culpa del plugin y no Jetbrains en realidad.

Espero que esto ayude.

Cristiano.

Sin saber exactamente qué está cambiando, es un poco difícil responder con confianza, pero yo diría:

  • Los files IWS contienen información que describe cómo se organiza el IDE de un desarrollador para este proyecto (incluyendo cosas como el historial de cambios recientes, el estado actual de cada window del editor, qué windows acoplables están visibles y cuáles se han queuepsado). Dado que a cada desarrollador se le debe permitir organizar su espacio de trabajo como prefiera, estos no deberían estar en control de fuente.

  • Los files IPR describen la estructura del código del proyecto. Con esto quiero decir cosas como qué modules son parte del proyecto, qué files build.xml usar, dónde encontrar bibliotecas para comstackr su código, etc. Esto puede estar en control de fuente, pero Si permite que estas configuraciones varíen de una copy del proyecto del desarrollador a la siguiente, tendrá una experiencia difícil.

Si tiene un componente libraryTable dentro de su file de IPR:

Casi con certeza, lo que está sucediendo es que cada desarrollador mantiene bibliotecas compartidas (JAR), necesarias para build su código, en su máquina local en diferentes lugares; cuando realizan cambios, la location de sus bibliotecas se escribe en el file IPR. Si tuviera que hacer esto, cuando actualicé el proyecto, mi copy del IPR y la suya entrarían en conflicto con la location de estos JAR.

Solucionamos este problema ubicando files JAR en una location compartida (como una unidad de networking mapeada) y luego aseguramos que cada desarrollador descargue estos files al mismo lugar (una subcarpeta lib bajo la raíz del proyecto funciona bien). La desventaja es que terminas con copys múltiples del mismo JAR en todos los proyectos (cada proyecto hará reference a su propia carpeta lib), pero al alza, como cada desarrollador está usando la misma estructura de proyecto, la actualización de IPR debería funcionar mucho mejor.

De otra manera:

Eche un vistazo para ver qué está intentando fusionar IntelliJ (cuando actualice, se le debe dar la opción de combinar manualmente los files o ver las diferencias; de lo contrario, use su herramienta diff favorita). Si pudieras actualizar tu pregunta con un poco más de información sobre cómo son tus conflictos de fusión, podría ser más fácil ver de dónde vienen las ruedas.

Agregamos una extensión a las que están marcadas en el control de origen (.deleteme). Entonces nuevas personas pueden verificar el proyecto, cambiar las extensiones e ir. Si hacemos cambios de configuration, actualizamos los files registrados.

Una solución es no poner sus proyectos IntelliJ en control de fuente. Esto implica que son fáciles de recrear.

Puede decirle a Subversion sobre los files que debe ignorar. Agregue sus files IntelliJ a esa list.

"… incluso sin haber realizado ningún trabajo en el proyecto …", esto sugiere que abra frecuentemente IntelliJ sin hacer ningún trabajo útil en el proyecto. Tal vez ese es el verdadero problema. No veo por qué abriría el IDE sin hacer ALGO que valiera la pena consultar. ¿Y cuál es el costo de un creciente número de revisión? Pequeño, en mi opinión.

Así que ahora he cambiado de opinión. Verifique los files del proyecto IntelliJ y no se preocupe por el aumento de los numbers de revisión. No te están costando mucho.