no se está registrando desde la raíz del proyecto

7

Cada vez que hago un check-in, siempre hago check-in desde la raíz del proyecto ... es decir, todos los archivos en mi copia de trabajo, así que después del check-in, el repositorio de control de origen contiene exactamente el mismo conjunto de archivos que acabo de probar en mi copia local. También me aseguro de que mi control de origen esté configurado para marcar los archivos locales que están no bajo el control de origen. En general, hay ninguno de estos archivos ... si los hay, los agrego al control de origen o los marca como "ignorados". También verifico todos mis cambios juntos en un registro.

Muchos colegas se registran de manera muy diferente. Seleccionan cuidadosamente cada archivo para registrarse, como si fueran un maestro joyero que selecciona solo las mejores gemas para colocar en la corona real, y registran cada una como un registro separado. Dependen solo de su memoria para descubrir qué archivos deben registrarse, o especialmente agregados al control de fuente.

Los resultados son bastante predecibles ... compilaciones rotas frecuentes porque se olvidan de agregar sus nuevos archivos al control de origen u olvidan registrar un archivo modificado (especialmente los archivos de proyecto modificados).

Les mencioné esto y nunca parecen cambiar. Cuando lo mencioné al líder del equipo, dijo, "esta es solo una forma diferente de trabajar". A lo que puedo responder: ¿Qué pasa si quiero conducir mi auto con los ojos cerrados? ¿Es solo "una forma diferente de conducir"?

¿Tengo razón al ser molestado por esta práctica?

    
pregunta JoelFan 31.10.2010 - 20:12

6 respuestas

11

No se moleste con la práctica de revisar archivos individuales: si alguien puede hacer eso y hacerlo funcionar, está bien.

Do ser molestado por personas que verifican construcciones rotas. La principal preocupación es el resultado. Abordar la causa raíz es absolutamente una buena idea, pero el mejor primer paso es encontrar la motivación adecuada para dejar de revisar el código dañado.

    
respondido por el nlawalker 31.10.2010 - 21:14
4

Si las compilaciones dañadas son un problema, sugeriría que evangelice las compilaciones automatizadas para su equipo. Si alguien registra un archivo que rompe la compilación, una compilación automatizada le indicará de inmediato, en lugar de esperar a que el próximo hombre venga y lo descubra, dedicando 15 minutos a rastrear a la persona que hizo el check-in que rompió la compilación (porque puede que no haya sido el último registro!) y así sucesivamente ...

Si la gente está revisando los archivos de una en una, puede demorar la compilación automatizada unos minutos después de que detecte un check-in, para permitir que las personas ingresen el resto de sus archivos. Este también es motivo de preocupación (pregunta: ¿ponen los comentarios correctos en el mensaje de confirmación?), Pero no es un problema tan grande como lo es romper la compilación.

    
respondido por el Dean Harding 31.10.2010 - 23:53
3

Sí, creo que tienes razón.

En el mejor de los casos (si siempre lo hacen correctamente), lo que están haciendo es solo una forma más lenta de hacer lo que estás haciendo.

El mayor problema es que está exponiendo prácticas de trabajo menos que ideales. En primer lugar, parece que están trabajando en más de una cosa a la vez, así que, en lugar de trabajar en pequeños pasos confiables, están realizando un gran cambio que es incomprensible y luego tienen que hacer otra tarea en el medio y comprometerse. O tal vez no se están limpiando, y sus cambios locales no comprometidos tienen todo tipo de basura (grandes bloques de código comentado, métodos redundantes, material roto que fue solo un experimento temporal).

He trabajado con personas que hacen esto y siempre es una pesadilla. La peor situación es cuando tienen basura no comprometida localmente, cuando se actualiza su versión local, pero algunas de las cosas que quieren mantener están en el mismos archivos que la basura. Como resultado, simplemente se pierden al ordenar las cosas que desean evitar de las cosas que desean revertir.

    
respondido por el FinnNk 31.10.2010 - 20:24
2

Las listas de cambios son un concepto impresionante. Solo un conjunto de cambios coherentes (que resuelve una cosa) debe formar parte de una lista de cambios única que se registra de forma conjunta.

Para agregar a mi respuesta: idealmente, debería poder construir una lista de cambios de sus archivos, pasarla a un alistamiento limpio (que está totalmente sincronizado con el repositorio) para aplicar la lista de cambios y construirla antes de registrarse. Si a tus compañeros de equipo no les molesta hacerlo, hazlo como parte del proceso de revisión del código.

    
respondido por el Amit Wadhwa 01.11.2010 - 05:48
1

Dejando de lado el problema ortogonal de cómo no olvidarse de agregar archivos a un lado, su enfoque puede llevar a otro problema: registrar accidentalmente los cambios que fueron solo para pruebas, etc.

La selección manual de los archivos de origen (o subdirectorios) para confirmar es un enfoque posible que se puede hacer de manera responsable y sin romper las compilaciones (utilizando la información de estado de su VCS). El problema real aquí es la distribución del conjunto de cambios en muchos registros diferentes, uno para cada archivo. Esto inevitablemente dará lugar a dificultades cuando el historial de versiones sea necesario para cualquier cosa.

    
respondido por el g.f 01.11.2010 - 04:38
1

Es posible trabajar un poco descuidado si tiene buenas herramientas para evitar que ocurran malas construcciones. En general, esto mantendrá al equipo más contento que exigiendo una vigilancia constante.

Configurar una compilación continua es el primer paso. Si las compilaciones dañadas son un problema, lo revelará.

Luego, podría escribir un script de envío que, dada una lista de archivos, compruebe el encabezado del proyecto en un nuevo directorio, los parche, ejecute pruebas y verifique los archivos juntos si pasan. Luego pueden elegir si lo desean, siempre y cuando utilicen el script de envío.

    
respondido por el Brian Slesinsky 01.11.2010 - 05:36

Lea otras preguntas en las etiquetas