Historial del archivo: en la fuente o let scm handle it?

Question

Estoy aprendiendo mercurial como mi software scm solo. Con otro software de administración, puede poner comentarios de cambio en el encabezado del archivo a través de etiquetas. Con hg usted comenta el conjunto de cambios, y eso no entra en la fuente. Estoy más acostumbrado al control central como VSS.

¿Por qué debería poner el historial de archivos en el encabezado del archivo fuente? ¿Debo dejar que mercurial administre la historia con mis comentarios changeets?

Answer 1

Deje que el sistema de control de fuente lo maneje.

Si pone los detalles de cambio en el encabezado pronto se volverá difícil de manejar y abrumará el código real.

Además, si el scm tiene el concepto de listas de cambios (donde muchos archivos se agrupan en un solo cambio), entonces podrá escribir el comentario para que se aplique al cambio completo y no solo a las ediciones en el archivo (si tiene sentido), que le da una idea más clara de por qué fue necesaria la edición.

Answer 2

Sí; deje que el sistema de control de origen maneje los comentarios de su conjunto de cambios. La razón de esto es que tiene mucho más sentido cuando está viendo el registro de cambios más tarde, tratando de resolver lo que sucede entre dos versiones de un archivo: el sistema de control de origen puede presentar el comentario de cambio para intentar aclarar la situación .

Answer 3

No hay razón para mantener manualmente un historial de archivos cuando el software SCM es mucho más adecuado para resolver este problema. Con demasiada frecuencia veo historias de archivos parcialmente completados en la fuente, lo que realmente duele, porque las personas asumen incorrectamente que es precisa.

Answer 4

No soy un gran defensor de ensuciar el código con comentarios de cambio. En caso de que sean necesarios, pueden buscarse en el SCM (al menos para las variantes de SCM que he usado). Si los quiere en el archivo, considere ponerlos al final en lugar de al principio. De esta forma, no tendrá que desplazarse hacia abajo más allá de los comentarios (poco interesantes, al menos para mí) antes de llegar al código real.

Answer 5

Tengo experiencia con esto. He tenido el historial de archivos en los comentarios, fue horrible. Nada más que basura, a veces tendrías que desplazarte hacia abajo casi 1k líneas de cambios de código antes de que finalmente llegaras a lo que querías. Sin mencionar, , estás ralentizando otros aspectos de tu proceso de compilación agregando más kb a tu árbol de código fuente.

Answer 6

Mucho más fácil de olvidar mantener el historial en la fuente, ya que uno siempre (imo) debería comentar se compromete con el sistema de control de fuente que desaparece el problema. Además, si se cambian muchos archivos antes de la confirmación, cambiar el historial en cada archivo será un trabajo molesto. Este es realmente uno de los puntos con tener scm.

Answer 7

Otro voto para permitir que el sistema SCM maneje los comentarios de registro, pero tengo una cosa que agregar.

Algunos sistemas le permiten utilizar etiquetas RCS en su código fuente donde el SCM puede insertar el historial de cambios directamente en el archivo fuente que se está confirmando automáticamente. Suena como un buen equilibrio porque la historia está entonces en el sistema SCM y luego se coloca automáticamente en el código fuente en sí.

El problema es que este proceso cambia el archivo de origen. Creo que es una mala idea porque el archivo no se puede cambiar en el disco hasta que se inserte un comentario. Si fueras un buen ingeniero, deberías haber creado y probado cambios antes de la confirmación.Si su fuente cambia después de la confirmación, entonces esencialmente tiene una compilación que podría romperse, pero la mayoría de los ingenieros no construirán después de una confirmación, ¿por qué deberían hacerlo?

¡Pero es solo un comentario que dices! Es cierto, pero tuve un caso en el que había código en mi archivo fuente que curiosamente tenía motivos para mirar como una etiqueta de encabezado RCS y esa sección del código fue reemplazada en el registro, por lo tanto cortando mi código. Lo suficientemente fácil de arreglar, pero malo que una construcción se rompió para más de 20 usuarios

Answer 8

La diferencia no es si se trata de un VCS centralizado o distribuido, se trata más bien de lo que se está cambiando.

Cuando me mudé a .Net, la cantidad de archivos actualizados para cualquier cambio individual pareció dispararse. Si tuviera que registrar el cambio en cada archivo, nunca obtendría ningún trabajo real. Al comentar sobre el conjunto de cambios, no importa cuántos archivos tuve que actualizar.

Si alguna vez tuve que identificar todos los cambios para un cambio en particular, puedo diferir entre las dos versiones del proyecto.

La mayor diferencia (y ventaja) que vi al cambiar de SourceSafe fue el cambio de archivo basado en confirmaciones basadas en proyectos. Tan pronto como me acostumbré a eso, dejé de agregar comentarios de tipo de registro de cambios a todos mis archivos.

(Como efecto secundario, he encontrado que los comentarios de mi descripción de proceso han mejorado)