¿Debería poner mis files de salida en control de fuente?

Me han pedido que ponga todos los files de mi proyecto bajo el control de código fuente, incluido el file de la database (no el esquema, el file completo).

Esto me parece incorrecto, pero no puedo explicarlo. Cada recurso que encuentro sobre el control de fuente me dice que no coloque los files de salida generados en un sistema de control de fuente. Y entiendo, no son files "fuente".

Sin embargo, me han presentado el siguiente razonamiento:

  • ¿A quien le importa? Tenemos mucho ancho de banda.
  • No me importa tener que resolver un conflicto cada vez que recibo la última revisión, es solo un clic
  • Es mucho más conveniente que tener que pensar en buenos files de ignorar
    • Además, si tengo que agregar un file DLL externo en la carpeta bin ahora, no puedo olvidar ponerlo en control de fuente, ya que la carpeta bin no se está ignorando ahora.

La solución simple para el último punto es agregar el file en una carpeta de bibliotecas y referencerlo desde el proyecto.

Por favor explique si y por qué poner files de salida generados bajo control de fuente es incorrecto.

No ha explicado qué es "el file de la database".

Ciertamente, includeía bibliotecas de terceros en control de código fuente, ya que son necesariamente para la compilation y es bueno tener una forma de reproducir una compilation en un momento posterior con las versiones de la biblioteca que utilizó en ese momento particular. Pero sí, esas bibliotecas deberían includese desde una carpeta "libraries" en lugar de desde el directory de salida.

En general, no includeía mis propias bibliotecas creadas a partir de fonts en otro lugar en el mismo repository, aunque he estado en situaciones en las que valía la pena hacerlo, donde algunos proyectos no usaban la "última y mejor" versión de una biblioteca común, pero solo de vez en cuando actualizado.

El argumento práctico más importante que daría en contra de include todo, en un mundo donde el disco, el procesador y la networking se consideran libres e instantáneos, es que hace que sea más difícil saber qué cambió realmente para un compromiso determinado. Es más fácil mirar hacia abajo una list de 3 files fuente que 3 files fuente y 150 binarys de los directorys obj / bin.

Los files de salida generados (en general) son "peligrosos" en un VCS porque:

  • lo que necesita para la versión es cómo regenerarlos: el día en que necesite actualizarlos, es probable que no recuerde cómo hacerlo
  • pueden contener algún file privado generado que los haga funcionar en el escritorio committer, pero no en uno cliente (síndrome de TM "works on my machine")
  • algunos files generados no se almacenan fácilmente en delta (especialmente binarys), por lo que consumen mucho espacio (y el tema de limpiar ese espacio aparecerá algún día …)

Las bibliotecas externas no son generadas directamente por su proyecto, y pueden colocarse en un VCS, aunque los repositorys externos como un repository público de Maven son mejores en este tipo de gestión.

¿También ponemos de nuestra fuente files de object comstackdos, como files de class, ejecutables, files DLL? ¿Qué pasa cuando estamos realizando testings serias de volumen y esa database se convierte en muchos gigabytes o terabytes de tamaño?

La pista está en el nombre: es el Sistema de Administración del Código Fuente .

Puedo entender la simplicidad de poner todo, es más probable que el desarrollador no olvide algún file importante. Pero si estás haciendo comstackciones automáticas regulares, ¿de todos modos eso se recoge?

Creo que la frase key está aquí:

Es mucho más conveniente que tener que pensar en buenos files de ignorar

¿Estás explícitamente prohibido tener buenos files de ignorar ? Supongo que ya estás excluyendo los files .exe y .class (o lo que sea). Supongamos que se toma la molestia de excluir su database ¿sería un problema? ¿Por qué? Es una acción consciente que estás eligiendo tomar para el commone bien. En Eclipse, es un par de segundos de trabajo agregar un nuevo tipo de file a las reglas de ignorar CVS del espacio de trabajo para todos los proyectos.

Una regla de "No Ignore Files" es casi evidentemente absurda. Una vez que tenga la libertad de tener algunos files de ignorar, ¿por qué no utilizarlos inteligentemente para excluir el DB? ¿Quién es molestado? Solo tú, si hay alguien, y estás preparado para hacer el trabajo extra.