¿Qué arguments existen contra la sustitución de palabras key como una característica en los sistemas de control de versiones?

¿Existen arguments en contra de la sustitución de palabras key (es decir, reemplazando $Revision$ con $Revision: 5$ ) como una característica en los sistemas de control de versiones?

No estoy buscando un debate. Estoy buscando arguments bien pensados ​​por personas que piensan que la function es una mala idea.

Aquí hay uno de esos arguments:

  • Substición de palabra key: por qué no la necesitas

Es sucinto, y creo que la discusión sobre los problemas que causa para los files binarys es convincente, pero no me parece convincente.

Una vez más, no estoy interesado en un debate, solo buenos arguments en contra de la function. Puedo tomar una decisión, pero quiero tener buenos datos para hacerlo.

Debo admitir que han pasado muchos años desde que utilicé la sustitución de palabras key en un sistema de control de versiones.

El más difícil de justificar es $Log$ . Parece una buena idea al principio, pero después de un time realmente comienza a saturar la fuente. La información está disponible fácilmente desde el sistema de control de versiones cuando sea necesario, por lo que tenerlo en el file es networkingundante.

Bueno, ¿qué arguments tienes para eso?

Si necesita información de la versión: "¿quién cambió qué, cuándo y por qué?" , pregunta en tu repository.

Si tiene treees fuente donde no puede decir qué versión son, o incluso treees fuente con files de diferentes versiones, podría estar haciendo algo mal (es decir: no puedo ver un caso de uso que lo justifique).

Además, la información puede ser completamente incorrecta. Cuando recojo un file del repository y lo edito, el encabezado aún dice "esto es revisión 124" . No es. Solo su informe puede indicarle que "este file difiere de la revisión 124 en los siguientes cambios:" .


He usado CVS solo durante una breve temporada, cuando toda esta versión, ¿qué? las cosas eran bastante confusas de todos modos. Nos hemos movido a través de VSS a GIT, y nunca me lo he perdido.

(Recuerdo que parecía ser importante para CVS).

Un argumento en contra es que el artículo al que se vincula llama un "punto de vista de integridad binaria": al comparar files de dos revisiones diferentes, obtendrá muchos falsos positivos debido a la modificación del sello de revisión.

Además, al actualizar una copy de trabajo en un proyecto que utiliza sustitución de palabras key, cada file tendrá que actualizarse, lo que puede ser costoso para el tráfico y de otra manera (por ejemplo, si está haciendo una copy viva de su copy de trabajo o algo así).

En realidad, no veo mucho problema en esto: si los efectos queueterales de la sustitución de palabras key van a ser un problema para su proyecto, simplemente no los use. En general, creo que es una gran característica.

Es una característica confusa, porque hace que el contenido "real" del file sea diferente de lo que obtienes en tu copy de trabajo. Esto lleva a las siguientes preguntas:

  • Qué sucede si edita el text sustituido en el file y confirma. ¿Se producirá un error en la confirmación? ¿Reemplazará la palabra key original en el file "real"? ¿Se ignorará el cambio?

  • ¿Cómo editas la palabra key en tu copy de trabajo? Después de todo, no se puede ver más en el file, se ha sustituido.

Después de leer cómo funciona en subversión , las respuestas no están del todo claras para mí. Tendría que intentar y ver para estar seguro. Para mí, eso es una indicación de que esta característica es más problemática de lo que vale.