A veces, cuando verificamos el historial de confirmación de un software, podemos ver que hay algunas confirmaciones que son realmente GRANDES: pueden cambiar 10 o 20 archivos con cientos de líneas de código fuente (delta) cambiadas. Recuerdo que hay un término de uso común para este gran compromiso, pero no puedo recordar exactamente cuál es ese término. ¿Alguien puede ayudarme? ¿Cuál es el término que los programadores suelen usar para referirse a este compromiso GRANDE y gigante?

Por cierto, ¿comprometer muchos cambios en conjunto es una buena práctica?

ACTUALIZACIÓN: ¡gracias a todos por la inspiradora discusión! Pero creo que "bomba de código" es el término que estoy buscando.

(1) Ben Collins-Sussman : "..." bombas de código ". Es decir, ¿qué haces cuando alguien se presenta a un proyecto de código abierto con una nueva característica gigantesca que tardó meses en escribirse? ¿Quién tiene tiempo para revisar? miles de líneas de código? ... "

(2) Dan Fabulich : "La bomba de código, o: el novato con grandes ideas ... Una bomba de código es un parche tan grande que nadie puede revisarlo".

(3) Google Summer of Code: Directrices : "Comprométase temprano, comprométase a menudo ... Por favor, no trabaje todo el día y luego empuje todo en una sola bomba de código . En cambio, cada compromiso debe ser autónomo para una sola tarea que debe resumirse en el mensaje de registro ".

(4) Jeff Atwood : "bombas de código ... Regla # 30: No te quedes oscuro ...

Probablemente lo llamemos un mal compromiso . :)

Mala práctica

Y sí, eso generalmente se consideraría una mala práctica , ya que tiene los efectos negativos de:

• haciendo que sea difícil de revisar ,
• haciendo que sea difícil captar fácil y rápidamente la intención original del commit ,
• haciendo que sea difícil ver cómo impactó el código para solucionar o resolver un problema explícitamente ,
• lo que dificulta saber si el tamaño de la confirmación se debe al ruido de otros cambios posiblemente no relacionados (por ejemplo, pequeñas limpiezas u otras tareas).

Casos aceptables

Sin embargo, puede tener casos en los que grandes confirmaciones son perfectamente aceptables . Por ejemplo:

• cuando se fusiona a través de ramas ,
• al agregar nuevas fuentes de otra base de código no versionada,
• al reemplazar una característica grande en el lugar (aunque debería hacerlo en una rama, con confirmaciones más pequeñas que aborden diferentes partes del cambio, y luego fusionar todo de nuevo, para que pueda tener una mejor ventana en el desarrollo incremental de la característica y los problemas que pueden haberse encontrado en el camino),
• al refactorizar una API que afecta a muchas clases descendientes y de consumo.

Por lo tanto, siempre que sea posible, prefiera los tipos de confirmaciones de "ataque quirúrgico" (¡y vincúlelos a las ID de tareas en su rastreador de problemas!). Si tiene una razón válida, continúe.

Aparte de eso, en realidad no sé y creo que nunca escuché un nombre especial para una gran confirmación. ¿Un monstruo comprometido? ¿Un compromiso gordo?

Actualización: la respuesta de David Cary se vincula con actores notables de TI que usan el término "bomba de código" (lo más importante, Collins-Sussman, creador original de Subversion ). Así (aunque hasta ahora no puedo decir que escuché si a menudo).

Por cierto, ¿comprometer muchos cambios en conjunto es una buena práctica?

Bueno, no es una buena práctica retener los cambios durante mucho tiempo e implementar una variedad de características y correcciones de errores, y luego confirmarlos, que es una de las formas en que podría ocurrir una gran confirmación.

Otra forma en que esto podría suceder es si una refactorización cambia la firma de una función ampliamente utilizada, y luego todas ellas deben cambiarse. Esto no es necesariamente malo, y no quisiera que los desarrolladores se abstengan de limpiar el código por temor a cruzar algún umbral.

Entonces, hay más que solo mirar la cantidad de archivos tocados en una confirmación.

El término que he escuchado es "registros gruesos" . Y no soy fanático de ellos. Me gustan los commits más pequeños que aseguran que nada más se rompa en un paso razonable en un proyecto. El gran compromiso generalmente está plagado de problemas que resuenan por un tiempo cuando eso sucede.

Lo llamo "confirmación SVN típica" o "mañana es la confirmación del día de lanzamiento"

Por mucho que me encante SVN, simplemente me desanima el hecho de que no puedo hacer commits locales.

EDITAR: generalmente tienen las palabras "cosas" y "cerveza" en el mensaje de confirmación.

EDITAR DE NUEVO: Cometer muchos cambios, aunque no necesariamente es una mala práctica, debe evitarse tanto como sea posible. Me resulta más fácil revisar una revisión / confirmación que es breve y concisa. (emparejado con un mensaje de confirmación bien escrito, vea mi edición anterior para un mal ejemplo)

Un "fragmento de código humeante". :-)

• confirmación inicial : el proyecto que no estaba bajo control de revisión lanzado en SVN
• refactorización : el arquitecto tiene una idea brillante sobre cambiar los nombres de clase de / a la Convención de nomenclatura de pitufos o cambiar la raíz de la jerarquía de paquetes
• formato de código : el arquitecto ha decidido cambiar la sangría del código de 4 a 3 espacios o cambiar las terminaciones de línea de Unix a Windows (o revertir)
• Compromiso del viernes : Joe siempre se compromete a trabajar toda la semana los viernes a las 16:30
• uuups commit : Ted eliminó por error el directorio raíz, lo confirmó y ahora bombea una vez más toda la jerarquía de archivos a SVN

Por lo general, muchas personas tienden a realizar una gran confirmación utilizando VCS centralizado, especialmente el servidor aplica una buena política de confirmación. Es decir, el commit debe pasar todas las pruebas y las pruebas toman más tiempo (más de unos segundos). Por lo tanto, los desarrolladores no quieren esperar tanto tiempo para confirmar varias veces y desglosar los cambios en varias pequeñas confirmaciones.

Y los desarrolladores que son ecológicos para VCS pueden olvidar dividir los cambios en múltiples pequeñas confirmaciones. Solo recuerdan comprometerse cuando lanzan el programa al equipo de control de calidad. Peor aún, para evitar que otros vean código defectuoso, no se comprometen antes de pasar con éxito las pruebas de control de calidad. Por último, no se dieron cuenta de que habían comprometido los archivos binarios de salida, los archivos temporales y la salida del enlazador, que realmente producen un compromiso "grande".