Historial del archivo: en la fuente o dejar SMC manejarlo?

Question

Estoy aprendiendo mercurial como mi software en solitario SMC. Con otro software de gestión, puede poner comentarios cambio en la cabecera del archivo a través de las etiquetas. Con hg de comentar el conjunto de cambios, y que no entra en la fuente. Estoy más acostumbrado al control central como VSS.

¿Por qué debería poner el historial de archivos en la cabecera del archivo de origen? ¿Debo dejar mercurial administrar el historial del conjunto de cambios con mis comentarios?

Answer 1

Deja que el sistema de control de origen de manejarlo.

Si pones detalles del cambio en la cabecera pronto se convertirá en poco manejable y abrumar el código real.

Además, si el SMC tiene el concepto de listas de cambios (en los que muchos archivos se agrupan en un solo cambio), entonces usted será capaz de escribir el comentario para que se aplique a todo el cambio y no sólo los cambios en el archivo de uno (si es que tiene sentido), que le da una imagen más clara de por qué se requiere la edición.

Answer 2

Sí; dejar que el sistema de control de origen manejar sus comentarios conjunto de cambios. La razón de esto es que hace mucho más sentido cuando esté viendo el registro de cambios más adelante, tratando de averiguar lo que está pasando entre dos versiones de un archivo - el sistema de control de código fuente puede presentar el comentario de cambio para tratar de iluminar la situación .

Answer 3

No hay ninguna razón para mantener manualmente un archivo de la historia cuando el software SCM es mucho más adecuado para resolver este problema. Todos los historiales de archivos Demasiado a menudo veo parcialmente completado en la fuente, que en realidad duele, porque las personas asumen incorrectamente que es correcta.

Answer 4

La diferencia no es si se trata de un VCS centralizados o distribuidos, se trata más de lo que está siendo cambiado.

Cuando me mudé a .NET, el número de archivos actualizados para cualquier cambio individual parecía dispararse. Si tuviera que registrar el cambio en cada archivo, que nunca conseguiría hacer ningún trabajo real. Comentando en el conjunto de cambios, no importa la cantidad de archivos que tenía que actualizar.

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

La mayor diferencia (y ventaja) vi cuando se cambia lejos de SourceSafe fue el cambio de archivos basado compromete a base de proyectos. Tan pronto como me acostumbré a eso, dejé de adición de tipo de cambio de registro de los comentarios a todos mis archivos.

(Como efecto secundario, me he dado cuenta que la descripción de mi proceso de comentarios han mejorado)

Answer 5

No soy un gran defensor de ensuciar el código con comentarios de cambio. En el caso de que se necesiten que se pueden consultar en el SMC (al menos para las variantes de SCM he utilizado). Si usted quiere en el archivo, tenga en cuenta que los pone en el final en lugar de al principio. De esa manera no tendrá que desplazarse hacia abajo más allá de la (poco interesante, al menos para mí) los comentarios antes de llegar al código real.

Answer 6

Otro voto por dejar que el sistema SMC manejar los comentarios registro, pero tengo una cosa que añadir.

Algunos sistemas permiten utilizar etiquetas de RCS en el código fuente donde el SMC puede insertar el historial de cambios directamente en el archivo de origen que se ha comprometido de forma automática. Suena como un buen equilibrio porque la historia está entonces en el sistema SCM y luego se pone automáticamente en el código fuente en sí.

El problema es que este proceso cambios en el archivo fuente. Creo que es una mala idea porque el archivo no se puede cambiar en el disco hasta después de que se inserta comentario. Si fueras un buen ingeniero, que debería haber construido y cambios antes de confirmar la prueba. Si cambia su fuente después de la confirmación, entonces usted tiene esencialmente una construcción que podría ser roto - pero la mayoría de los ingenieros no va a construir después de una confirmación - ¿por qué habrían de hacerlo

Pero es sólo un comentario que dice! Es cierto, pero tuve un caso en el que no había código en mi archivo de origen que curiosamente tenía razones para buscar como una etiqueta de cabecera RCS y que el artículo del código consiguieron reemplazados en el registro, munging con ello mi código . Es bastante fácil de solucionar, pero mal que la acumulación se rompió por más de 20 usuarios

Answer 7

Mucho más fácil de olvidar para mantener la historia en la fuente, como siempre (OMI) debe comentar compromete a la fuente de sistema de control que dissappers problemas. Además, si el cambio de un montón de archivos antes de cometer, cambiando la historia de cada archivo será un trabajo molesto. Esto es realmente uno de los puntos con tener SMC.

Answer 8

Tengo experiencia con esto. He tenido el historial de archivos en los comentarios, que era horrible . Nada más que basura, a veces se tendría que desplazarse hacia abajo casi 1k líneas de cambios en el código antes de que finalmente consiguió lo que quería. Por no mencionar, uno va frenando otros aspectos de su proceso de construcción mediante la adición de más kb a su árbol de código fuente.