¿Hay un sistema de control de fuente de "doble logging de usuario"?

¿Hay algún sistema de control de fuente que requiera que otro usuario valide el código fuente "antes" de que pueda registrarse?

Quiero saber que esta es una técnica para garantizar que la calidad del código sea alta.

Actualización: Se ha hablado de "Sucursales" en las respuestas, y si bien creo que las sucursales tienen lugar, creo que las sucursales son algo diferente, ya que cuando un código de desarrollador está listo para ir a la sucursal principal "debería" verificarse. Muy a menudo, sin embargo, veo que cuando esto sucede, un desarrollador líder o quien sea responsable de la fusión en la twig / secuencia principal simplemente coloca el código en la twig principal siempre que "compile" y no haga más comprobaciones. Quiero la idea de que dos personas pongan sus nombres en el código en una etapa temprana de modo que se asigne cierta responsabilidad, y también porque el código es más barato de arreglar desde el principio y también está fresco en la mente de los desarrolladores.

Una solución que intenta resolver el problema es Kiln by FogCreek: http://www.fogcreek.com/Kiln/ – esto muestra que lo que quiere no es del todo irrazonable.

Genéricamente, creo que esto se trata más de cómo organizar cosas que sobre herramientas específicas, que si una herramienta tiene características que ayudan a respaldar el flujo de trabajo que necesita, obviamente eso va a ayudar.

Creo (aunque ahora estoy luchando para encontrar references) que hay herramientas que tienen la noción de un punto de detención antes de comprometerse, de modo que el desarrollador se compromete pero los cambios se "mantienen" hasta que se aprueben. O eso o hay herramientas de revisión de código que administran los ganchos para usted (estoy frustrado porque he leído esto pero no puedo encontrarlo esta mañana).

En general, por lo que he visto, esto sugiere que un DVCS (mercurial, git, bazaar et al) podría ser la solución más adecuada, con el paso de revisión siendo el impulso para su repository central, esto resuelve el conflicto entre "cometer a menudo" "y" revisar antes de confirmar ". La alternativa, como se sugiere, es que trabaje en twigs de desarrollador y revise antes de la fusión. En ambos casos, la cuestión key es más gestión que set de herramientas: debe asegurarse de que los atrasos no se acumulen (de código potencialmente "malo") debido a la incapacidad o falta de voluntad para get una revisión e integración del código.

He hecho esto en TFS al eliminar los derechos de logging para el grupo objective. Ahorrarían en sets de distribución y notificarían a un grupo de revisores que tiene el derecho de "registrarse como otro".

(Este debería ser el penúltimo recurso, pero cuando codifique así:

if (expr == false || expr.ToString() == "false") { ... 

es común, uno debe tomar medidas. El paso final fue replace a varios miembros del equipo y garantizar que entrevistáramos a los nuevos reclutas, no solo al gerente de la location off-shore).

Usando la subversión (por ejemplo), esto podría lograrse usando dos twigs con diferentes derechos de acceso:

  • Tienes la twig donde todos pueden comprometerse (check-in) para
  • Luego tiene otra sucursal, donde solo una (o algunas) personas tienen acceso de escritura. Estas personas podrían verificar las confirmaciones en la primera twig y fusionarlas a la segunda twig si todo está bien.

Por cierto: probablemente no recomendaría este enfoque, porque podría generar demasiada sobrecarga. Probablemente probaría otro enfoque para la revisión / aprobación de código, por ejemplo, usando alguna herramienta como ReviewBoard y hacer las revisiones de código con todo tu equipo (para aprender / mejorar).

Las herramientas de git tienen un concepto de 'firmado por', que los mantenedores pueden usar al fusionar o aplicar parches en su tree 'oficial', sea lo que sea que eso signifique en su process. En un proyecto como el kernel de Linux, sin firma, sin integración. Puedes usar ese process.

No conozco ningún SCM que lo haga de manera inmediata, principalmente porque se trata de un problema de process / worflow, no de un problema de gestión de control de origen.
Además, como otras personas han dicho correctamente, desalentar los loggings regulares de su depósito es una mala cosa y comienza a socavar el punto de tener una solución SCM en primer lugar.
Así que vas a tener que hacer algo de 'enrollarte', ya que solo tú sabes el process exacto que quieres lograr.
Así es como lo haría a la fuerza:
1) Cada codificador crea una twig de usuario
2) Todos los cambios se verifican en su twig de usuario y nunca en la twig principal
3) El codificador solicita que su código sea promovido a main:
i) El código se revisa (ya sea manualmente sincronizándolo con su twig de usuario o mediante alguna herramienta de revisión de código como CodeCollaborator o Crucible)
ii) El código está marcado como "limpio"
4) El usuario luego integra la twig principal a su twig de usuario y resuelve cualquier conflicto de fusión
5) El código se integra luego a main.

Todavía hay problemas que resolver con este enfoque, es decir, si entre los pasos 4 y 5, alguien más se ha integrado a main, entonces tendrá que volver a realizar el paso 4, por lo que debería considerar tener un único integrador o un locking exclusivo en el principal paso de integración

Otra opción si está utilizando forzosamente es usar activadores forzados. Se ejecuta un desencadenador en el server y puede escribir cualquier secuencia de commands que desee validar la list de cambios y su descripción. Si confías en las personas, puedes rechazar cualquier list de cambios que no tenga la frase "Revisado por:" en la descripción de la list de cambios. Si no confía en las personas, necesita que el MD5 del diff esté firmado por la key privada del guardián. Esa segunda solución es más complicada para escribir.