¿Cómo explicaría los riesgos de la palabra clave $ Log $?

Question

Parece que entro en un debate anual sobre el uso de la palabra clave $Log$. Mi punto de vista es este:

$Log$ es muerte en caliente.

Todo lo que hace es atascar el correo no deseado marginalmente relevante en sus archivos de origen. Cualquier información que alguien piense que pueda obtener de un $ Log $ está más fácilmente disponible de (y es probable que sea más precisa en) su sistema de control de versiones.

Así que, aquí está la pregunta: ¿cómo explicarías a un codificador de la "vieja escuela" (que piensa que $ Log $ es la forma de gestionar los cambios del código fuente) que tenemos mejores herramientas ahora?

The CVSNT remarks on $Log$ are a good start pero no son lo suficientemente puntiagudas. Hasta la fecha, lo más cerca que he llegado a un trazador de líneas que he logrado encontrar es "$Log$ es un deseo. Estás esperando que lo que se envía a tu archivo ha cualquier relación a lo que realmente le sucedió a este archivo ".

PD para mayor claridad: cuando digo "vieja escuela", quiero decir viejo en actitud, no viejo en años. Mi primer cheque de programación (y también notablemente modesto) fue en 1986 y nunca pensé que $ Log $ fuera una buena idea.

Answer 1

Creo que el Subversion FAQ también tiene una buena explicación.

$ Log $ es un horror total en el momento en que comienza a fusionar los cambios entre sucursales. Prácticamente está garantizado para obtener conflictos allí, que, debido a la naturaleza de esta palabra clave, simplemente no puede ser resuelto automáticamente.

Answer 2

Además de lo que han dicho los demás, intente poner un comentario (/ * ... * /) en un mensaje de confirmación: ->.

Answer 3

La cantidad de bits útiles en un archivo de origen disminuye lentamente a medida que se realizan cambios con la sentencia $ Log $. Lo teníamos en algunos archivos que venían de CVS y el número de líneas de $ Log $ era del orden de 10 veces más que el código ejecutable en el archivo en realidad. Y tenía algunos grupos de duplicados causados ​​por malas fusiones de algunas sucursales.

Answer 4

usted puede considerar (énfasis en puede) incrustar inmutables meta-datos en el archivo.
(Ver el debate entre mí y un "alumno de mayor edad": Embedded Version Numbers - Good or Evil?).

Aunque siempre he considerado esta práctica como malvada (mezcla de información de metadatos en datos), presentando "fusión infernal", se podría argumentar que podría funcionar, con el administrador de combinación correcto, para metadatos inmutables con un formato fijo, como:

• $ $ $ Revisión Revisión: 9.13 $
• $ $ $ Fecha Fecha: 2009/03/06 06:52:26 $
• $ $ $ RCSfile RCSfile : stderr.c, v $

¿Pero los metadatos mutables como registros? ¿Con formato o contenido desconocido? Eso está destinado a fallar.