2010-08-04 15 views
11

Esto se puede reducir a la opinión: Me pregunto si los archivos de proyecto (los archivos generados y utilizados por el IDE y no el compilador) deberían incluirse en los repositorios de control de código fuente. ¿Hay ciertos casos en que deberían y no deberían?¿Los archivos del proyecto IDE deberían estar bajo el control de la fuente?

Editar: Debo mencionar que la razón por la que estoy preguntando es porque estoy viendo algunas listas de archivos para ser ignoradas por git cuando uso Visual Studio - algunas de estas listas tienen los archivos del proyecto y otras no .

+0

Demasiado malo hombre. Los programadores reales usan vim (que apesta), emacs o mariposas. Quiero decir, mariposas reales: D –

Respuesta

14

Una pregunta simple: ¿Usted necesita para construir su código? Si no, entonces son artefactos, no archivos fuente, y no tienen lugar en el sistema de control de origen.

Cosas como las preferencias de color de su editor o las combinaciones de teclas no son parte del sistema de compilación. Los indicadores del compilador y demás son.

Almacenamos todo lo que se necesita para compilar, hasta el sistema operativo instale los discos y la configuración requerida. Anal-retentive ni siquiera se acerca a describirnos :-) Si pudiéramos almacenar el hardware, lo haríamos (tenemos que arreglárnoslas con el almacenamiento de un documento que detalla las especificaciones de hardware).

También ocasionalmente probamos nuestra capacidad para construir el entorno de desarrollo desde cero utilizando solo lo que está almacenado en los repositorios. El fracaso significa que no estamos cubiertos en términos de recuperación de desastres.

+0

Un archivo README.md no es ni código fuente, ni es necesario para compilar código. Sin embargo, este es probablemente el primer archivo que crearía con un nuevo repositorio de git/bitbucket. – Mahesh

2

Si tiene scripts de compilación especiales, es posible que el IDE necesite crear su proyecto. Además, si haces un checkout nuevo, ¿realmente quieres pasar por la molestia de configurar todos los parámetros de compilación del proyecto, etc. cada vez?

2

Si trabaja con otros desarrolladores y no usan otro IDE u otras versiones de IDE, los archivos del proyecto IDE no serán los mismos. Creo que los archivos del proyecto IDE no deben ponerse bajo el control de la fuente.

0

Usamos Eclipse y el único archivo que registramos es el archivo .classpath de modo que cualquier cambio en la ruta de clase no rompa la construcción en una actualización.

5

Es más fácil y lógico para mí incluir archivos de proyecto en los repositorios, ya que son parte del proyecto en sí. Cambios de proyecto, archivos de proyecto también.

Cuando tenga que revertir todo el proyecto al estado anterior o invitar a alguien a registrarse para trabajar en el proyecto, es mucho más conveniente tener cada archivo. No solo el código fuente

Por cierto, la mayoría de los IDE incluyen los archivos del proyecto en repositorios, y será muy doloroso excluirlos y aún así tener la posibilidad de registrarse y salir del propio IDE.

+1

Acepto, lo considero un tipo especial de documentación, ya que la configuración del proyecto puede mostrar una estructura general del código. –

+0

+1. Si un proyecto sigue reglas de formato de código específicas de la organización, la definición de formato es __not__ code per se (piense en el archivo XML de reglas de formato de Eclipse), pero dado que cada desarrollador debe tener la misma definición de reglas de formateo, tiene sentido registrar esto para controlar la fuente – Mahesh

1
  • mantener bajo control de versiones de todos los archivos de proyecto que son necesarios para construir el Proyecto
  • derivados evitar la adición (por ejemplo. Ctags, y todos los archivos que se pueden generar)
2

general, los archivos de proyecto debe ser controlado por la versión, pero los archivos de preferencia del usuario deben ignorarse.

Por ejemplo, al usar Visual Studio, los archivos '.proj' y '.sln' deberían tener la versión controlada, pero '.suo 'debe ser ignorado.

0

Los archivos de proyecto que incluyen instrucciones de compilación definitivamente deben estar bajo el control de código fuente. No desea establecer el compilador correcto y las banderas y la ruta del enlazador en cada nueva extracción, ¿verdad?

Sin embargo, no todos los archivos de proyecto son iguales, y algunos son solo "archivos de ayuda" que almacenan etiquetas o recientemente abrieron archivos, etc. Esos no deben ser versionados, ya que pueden variar para cada desarrollador.

Hay dos beneficios diferentes de versionning archivos de proyecto:

  • uno es más fácil developping. Especialmente para un nuevo desarrollador. Todo lo que tienes que hacer para comenzar a trabajar es hacer un pago.
  • el otro es tener una construcción reproducible. Ya sea que la construcción provenga del desarrollador A o del desarrollador B, el objeto resultante es el mismo. Este es el beneficio más importante de IMO, y es un paso hacia la automatización de la construcción.
0

Estoy trabajando para una empresa que desarrolla y vende un IDE. Al principio eliminamos todos los archivos de proyecto de los directorios de usuario. La mayoría de la gente estaba feliz con esto. Pero de vez en cuando alguien preguntaba si era posible porque querían trabajar desde su sistema doméstico y utilizaban el control de versiones como una herramienta de transferencia de archivos rápida que sincronizaba el trabajo y el lugar de origen.

¡Puedo decirle que implementar esta solicitud no fue fácil!

La configuración debe estar claramente separada, por ejemplo, si su IDE almacena coordenadas de ventana en el archivo de configuración y trabaja en el sistema de monitor doble en el trabajo y una pequeña notebook en casa es realmente malo. El IDE también debe ser capaz de proporcionar una forma de gestionar la expansión de variables de entorno en cada ruta de archivo. Y, por supuesto, debe ser capaz de dar a los archivos de configuración nombres individuales o almacenarlos en diferentes lugares; de lo contrario, pronto descubrirá que 3 desarrolladores diferentes en el proyecto tienen 5 opiniones diferentes sobre fuentes, colores, valores predeterminados, etc. no está bien hecho, todos usarán la misma configuración.

Por otro lado, muchos IDEs tienen grandes cantidades de datos para almacenar, algunos de ellos incluso almacenan casos de prueba de unidades configuradas con GUI en la configuración del proyecto. En este caso, es útil reutilizar los archivos y verificarlos en el sistema de control de versiones.

Así que verá que depende. Pruébelo y vea cómo funciona para su entorno.

1

Para .NET, creo que los archivos del proyecto deben incluirse en los repositorios de control de código fuente. En C# y VB, es el archivo del proyecto el que define qué archivos fuente forman parte del ensamblaje. Si agrega un archivo fuente al proyecto y no tiene el archivo de proyecto bajo control de fuente, todos los demás desarrolladores en el equipo deben agregar manualmente el archivo a SU proyecto.

En Java, todos los archivos de un árbol fuente se incluyen automáticamente en la compilación (si mal no recuerdo), por lo que la necesidad de un archivo de proyecto puede no ser la misma en Java.

0

Sí, creo que los archivos de proyectos IDE deberían estar comprometidos con Subversion ya que la mayoría de estos incluyen configuraciones sobre cómo compilar/construir el proyecto.

Si hay configuraciones que se utilizan únicamente para almacenar las preferencias del desarrollador fuera de la convención de codificación, deben eliminarse (es decir, excluirse) para no crear confusión.

0

No estoy seguro si fue mencionado, pero Visual Studio (al menos la versión de C++) produce dos archivos de proyecto:

  1. archivo de proyecto general que contiene la estructura y la configuración de construir. Esto es necesario para construir con VS.
  2. Archivo de proyecto específico del usuario (generalmente termina con el nombre del usuario y de la PC). Este no es obligatorio para la construcción, por lo que no lo incluiremos en el control de origen.
Cuestiones relacionadas