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

Usamos ClearCase en mi lugar de trabajo. Parte de nuestro process estándar cuando el código se fusiona con la twig principal (troncal) es erradicar por completo todas las versiones en las twigs de desarrollo e integración. Como esto borra todos los comentarios de check-in que acompañan a estas versiones, nuestros files fuente deben tener un prólogo largo que identifique cada cambio.

En algunas ocasiones señalé que esto niega una de las razones fundamentales para usar un sistema de control de versiones, y establecí que al eliminar versiones es imposible ver quién trabajó originalmente en algo, cuándo se introdujeron los problemas, etc. las nuevas versiones han aprendido a no molestarse en ingresar un comentario de check-in porque de todas maneras se eliminará.

La justificación que he escuchado para eliminar las versiones anteriores generalmente se ha networkingucido a razones de "sentirse bien". Mis compañeros de trabajo más experimentados sienten que eliminar estas viejas twigs hace que los treees de versión para files sean "más limpios". Afirman que no hay ninguna razón para mantener estas versiones antiguas una vez que se haya fusionado con nuestro baúl. También les preocupa que otros desarrolladores accidentalmente mantengan estas twigs desactualizadas en sus especificaciones de configuration de vista . Finalmente, argumentan que la eliminación de estas twigs ahorra espacio en disco en el server CM.

¿Tengo razón al tener un mal presentimiento sobre esto, o hay otras tiendas de desarrollo que operan con éxito de esta manera? Si también crees que esta es una mala idea, ¿qué otros arguments a favor de mantener versiones anteriores suministrarías? Si ha operado exitosamente con este tipo de process, ¿qué tipo de beneficios ha observado?


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

Ya ha notado un gran problema: con la eliminación de comentarios de compromiso, no hay un logging 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 ser o no 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 culpa" para encontrar en qué revisión apareció la línea y verificarla desde allí. Esto generalmente conducirá a la comprensión del propósito del código, y me dará una pista de lo que podría romper al cambiarlo. También suele ser útil encontrar cuándo se agregó o eliminó una característica.

Si bien esto puede ahorrar algo de espacio, un buen VCS almacenará los deltas y por lo tanto no ocupará tanto espacio extra (nota: no sé si ClearCase es bueno de esta manera). Mientras tanto, los files que estás usando están hinchados por los comentarios del prólogo y probablemente por el código que está comentado o comstackdo de forma condicional en caso de que te 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 ser, y está causando problemas (puede ser muy grande, por ejemplo, algunas personas han tenido problemas cuando alguien ha cometido no solo los files fuente sino todos los binarys), y el otro es si es inapropiado (como información confidencial).

Si hay algo que no se hace 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 get su contenido correcto, y de manera más general, de eso se trata el historial de files. (y el historial de fusiones: rmver eliminará todos los xhlinks, es decir, todos los hyperlinks, como la información de fusión)

Si realmente quieres limpiar el historial: cleartool lock -obsolete es la respuesta correcta.
Simplemente obsolese las twigs viejas del baúl que ya no quiere ver. Por lo general es más que suficiente.

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

  • nuevas versiones con "contenido incorrecto" que no pretendía versión alguna: si es la última, sin label o hyperlinks, podría eliminarla en lugar de cambiarla …
  • Los files binarys de gran tamaño evolucionan muy a menudo (luego, las versiones antiguas podrían ahorrar espacio). Todos los demás types de files no saveán un lugar importante al eliminar sus versiones antiguas.

No tiene sentido para mí por qué usarías el control de versión 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 time. Me encuentro constantemente revisando versiones anteriores de files para descubrir por qué o cómo se cambió algo.

Esto ha sido especialmente útil a medida que los requisitos evolucionan y te das count de que realmente necesitas ese código que escribiste hace tres meses.

Eliminar versiones es incomprensible para mí. Parece que sus compañeros de trabajo están intentando demostrar a testing de idiotas el uso de ClearCase en lugar de proporcionar documentation, soporte y capacitación adecuados sobre sus capacidades.

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

No hay beneficios para eliminar la información de revisión. Incluso la información de revisión sin comentarios de logging es 1000 veces mejor que ninguna 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 files) es que cuando encuentra un error y un retroceso al logging donde se introdujo el error, generalmente es una buena idea search loggings por el mismo usuario en el mismo momento . El error puede ser más extenso de lo que parece. No se puede hacer eso sin información de revisión.

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

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

  1. Si desea un tree fuente "más limpio", hay muchas otras características que no implican destruir información. La mayoría de los sistemas de control de origen pueden colocar elementos en un estado eliminado que está oculto de las UI estándar (a less que active las opciones especiales); imponer permissions de lectura por artículo; mueva los artículos a un área pnetworkingefinida del tree (por ejemplo, un lugar llamado "Cosas viejas"); O todo lo anterior.

  2. Que yo sepa, cada sistema SCC que sea lo suficientemente potente como para soportar especificaciones de vista personalizada 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 el almacenamiento de compression + delta. Solo en unas pocas aplicaciones de nicho donde están involucrados files binarys grandes, 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 describes. Me gustaría mantener instantáneas en intervalos pnetworkingefinidos en su lugar. Diga: todas las revisiones durante 2 semanas, luego diariamente durante las 2 semanas anteriores, semanalmente durante algunos meses antes de eso, luego mensualmente de return al comienzo.

En resumen, el time del desarrollador es muy costoso. Unos pocos minutos de administración CC + unos pocos discos duros adicionales en la SAN ni siquiera se pueden comparar.

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

Sin un historial de control de versiones, es muy útil una herramienta de "debugging" muy útil, la búsqueda del historial de errores (por bisección) para encontrar la primera revisión que introdujo el error. Cuando encuentre una confirmación que introdujo el error (algunos VCS brindan el command "scm bisect" para ayudar con esto, incluso para completar la automation si tiene una testing con scripts), y siguió buenas prácticas de control de versiones de ediciones pequeñas, únicas y bien descritas , entonces es muy fácil encontrar dónde está el error.