¿Tiene sentido eliminar permanentemente versiones de un VCS como parte de un proceso de desarrollo normal?

Question

Utilizamos ClearCase en mi lugar de trabajo. Parte de nuestro proceso estándar cuando el código se combina con la rama principal (troncal) es erradicar completamente todas las versiones en las ramas de desarrollo e integración. Debido a que esto borra todos los comentarios de registro que acompañaron a estas versiones, nuestros archivos de origen deben tener un extenso comentario de prólogo que identifique cada cambio.

En algunas ocasiones he señalado que esto niega una de las razones fundamentales para usar un sistema de control de versiones, y afirmé que al eliminar las versiones es imposible ver quién trabajó originalmente en algo, cuando se introdujeron problemas, etc. Las personas que registran nuevas versiones han aprendido a no molestarse en ingresar un comentario de check-in porque de todos modos solo se eliminará.

La justificación que he escuchado para eliminar las versiones antiguas generalmente se reduce a "sentirse bien". razones. Mis compañeros de trabajo más experimentados sienten que eliminar estas ramas viejas hace que los árboles de versión para archivos sean más limpios. Afirman que no hay ninguna razón para mantener estas versiones antiguas una vez que se han fusionado con nuestro tronco. También les preocupa que otros desarrolladores mantengan accidentalmente estas ramas desactualizadas en sus ver especificaciones de configuración . Finalmente, argumentan que eliminar estas ramas ahorra espacio en disco en el servidor CM.

¿Tengo razón en tener un mal presentimiento sobre esto, o hay otras tiendas de desarrollo que operan con éxito de esta manera? Si también piensa que esta es una mala idea, ¿qué otros argumentos a favor de mantener versiones antiguas proporcionaría? Si ha operado con éxito con este tipo de proceso, ¿qué tipo de beneficios ha observado?

---

Editado para aclarar: las versiones anteriores del tronco siempre se conservan. Son las ramas donde originalmente se crearon o modificaron las cosas que se eliminan.

Answer 1

Ya has notado un gran problema: con la eliminación de los comentarios de confirmación, no hay un registro automático de cómo el código llegó a ser como es. Tampoco hay manera de examinar la historia de cómo el software llegó a ser como era: es un gran bulto, con grandes comentarios de prólogo que pueden o no ser precisos.

Con frecuencia, cuando encuentro un código que parece extraño, quiero saber cómo llegó a ser. Como usamos Subversion, puedo usar '' svn blame '' para encontrar en qué revisión apareció la línea y verificarla desde allí. Esto generalmente conducirá a comprender el propósito del código y me dará una idea de lo que podría romper al cambiarlo. También suele ser útil encontrar cuándo se agregó o quitó una función.

Si bien esto puede ahorrar algo de espacio, un buen VCS almacenará deltas y, por lo tanto, no ocupará tanto espacio extra (nota: no sé si ClearCase es bueno de esta manera). Mientras tanto, los archivos que está utilizando están hinchados por los comentarios del prólogo y probablemente por el código que está comentado o compilado condicionalmente en caso de que sea útil más adelante.

Como alguien que solía administrar un sistema VCS, solo hay dos razones para eliminar algo del sistema. Una es si algo se comprometió que no debería, y está causando problemas (puede ser muy grande, por ejemplo, algunas personas han tenido problemas cuando alguien cometió no solo los archivos de origen sino todos los archivos binarios), y la otra es si es inapropiado (como información confidencial).

Answer 2

Si hay algo que no debe hacer con ClearCase es eliminar la versión.
Nunca. (Casi nunca de todos modos).

ClearCase se basa en gran medida en delta, sus líneas de base se pueden establecer en modo incremental y necesitarán versiones anteriores para que su contenido sea correcto, y en general, el historial de los archivos es de lo que se trata. (e historial de fusiones: rmver eliminará todos los enlaces x, es decir, todos los hipervínculos, como la información de combinación)

Si realmente quiere limpiar el historial: cleartool lock -obsolete es la respuesta correcta.
Simplemente obsoleto las viejas ramas del tronco que ya no quieres ver. Por lo general, es más que suficiente.

Los únicos casos en los que se podría justificar la eliminación de la versión serían:

• nuevas versiones con " contenido incorrecto " no tenía intención de versionar en absoluto: si es el último, sin etiqueta o hipervínculos, puede eliminarlo en lugar de cambiarlo ...
• archivos binarios grandes que evolucionan muy a menudo (entonces rmver para versiones antiguas en realidad podrían ahorrar espacio). Todos los demás tipos de archivos no guardarán un lugar significativo al eliminar sus versiones anteriores.

Answer 3

No tiene sentido para mí por qué usarías el control de versiones si no vas a mantener las versiones.

El principal beneficio del control de versiones, en mi opinión, es la capacidad de retroceder en el tiempo. Me encuentro constantemente revisando versiones anteriores de archivos para averiguar por qué o cómo se cambió algo.

Esto ha resultado especialmente útil a medida que evolucionan los requisitos y descubre que realmente necesitaba ese código que escribió hace tres meses.

Answer 4

Eliminar versiones es incomprensible para mí. Parece que sus compañeros de trabajo están tratando de probar el uso de ClearCase en lugar de proporcionar la documentación, el soporte y la capacitación adecuados sobre sus capacidades.

Desafortunadamente, yo también he encontrado situaciones muy similares. Al comenzar proyectos futuros, debe intentar hacer argumentos limpios y claros sobre cómo cree que debe hacerse el control de versiones. Tal vez si el proceso con el que comienza el proyecto se establece correctamente, todos verán las ventajas y las aplicarán a proyectos futuros.

Answer 5

No hay beneficios al eliminar la información de revisión. Incluso la información de revisión sin comentarios de registro es 1000 veces mejor que sin información de revisión.

El caso más convincente para mantener la información de revisión (más allá de la recuperación de archivos) es que cuando encuentra un error y retrocede al registro donde se introdujo el error, generalmente es una buena idea buscar registros por el mismo usuario. al mismo tiempo. El error puede ser más extenso de lo que parece. No puedo hacer eso sin información de revisión.

Cambiar trabajos. Vivirás más tiempo. Trabajar con programadores que no entienden los beneficios del control de versiones no puede ser bueno para su salud continua.

Answer 6

No, no creo que los beneficios superen los costos. Los costos son obvios (y están bien cubiertos por las respuestas existentes), así que abordaré los llamados beneficios.

1. Si quieres un " limpiador " árbol fuente, hay muchas otras características que no implican la destrucción de información. La mayoría de los sistemas de control de origen pueden colocar elementos en un estado eliminado que está oculto de las interfaces de usuario estándar (a menos que active las opciones especiales); hacer cumplir los permisos de lectura por elemento; mover los elementos a un área predefinida del árbol (por ejemplo, un lugar llamado "Old Stuff"); o todo lo anterior.

2. Que yo sepa, cada sistema SCC que sea lo suficientemente potente como para admitir especificaciones de vista personalizadas también permite a los administradores auditar y sobrescribir estas configuraciones.

3. El código fuente simplemente no es tan grande. Especialmente después de considerar la compresión + almacenamiento delta. Solo en algunas aplicaciones de nicho donde están involucrados grandes archivos binarios podría considerar la eliminación permanente. (Por ejemplo, los estudios de desarrollo de juegos pasan por una TONELADA de ilustraciones y videos de alta resolución). Aun así, mi política de retención no sería tan descarada como la que usted describe. En su lugar, mantendría instantáneas a intervalos predefinidos. Diga: todas las revisiones durante 2 semanas, luego diariamente durante las 2 semanas anteriores, semanalmente durante algunos meses antes de eso, luego mensualmente de regreso al principio.

En pocas palabras, el tiempo del desarrollador es realmente caro. Unos minutos de administración CC + unos pocos discos duros adicionales en la SAN ni siquiera se comparan.

Answer 7

Poder culpar a alguien por un cambio específico a menudo es muy útil. Una vez que todos los cambios están en el tronco, se pierde toda la información sobre quién escribió qué y por qué lo hizo. Ser capaz de mostrarle a alguien que "Aquí - Tú hiciste esto, allí" a menudo es muy útil en sí mismo, incluso sin los comentarios de confirmación.

Answer 8

Sin un historial de control de versiones, una "depuración" muy útil La herramienta, de búsqueda de errores en el historial (por bisección) para encontrar la primera revisión que introdujo el error, es imposible. Cuando encuentre un commit que introdujo un error (algunos VCS proporcionan el comando '' scm bisect '' para ayudar con esto, incluso hasta completar la automatización si tiene una prueba con script), y siguió buenas prácticas de control de versiones de un solo problema pequeño, bien descrito confirma, entonces es muy fácil encontrar dónde está el error.