pre-commit code review

Question

Me gustaría tener ese escenario: tengo un repositorio y mucha gente comprometida con él. Para algunos de ellos, prefiero ver su código primero, antes de permitirles enviar su código.

Hay muchas buenas herramientas de código de revisión, pero ninguno en realidad me permite fácil apoyo este flujo de trabajo:

• editar el código.
• Envíe fácilmente su código desde su herramienta de elección (es decir, Eclipse) para revisar el sistema.
• Haga que el código sea aprobado por otra persona en el sistema de revisión.
• Presente el código. El repositorio lo revocará si no se aprueba.

quiero evitar situaciones en las que la gente tiene que crear diferenciaciones, enviarlos a mí por correo electrónico, voy a tener que parchear ellos ... Eso debería ser un flujo de trabajo utilizable, intutive que no agrega sobrecarga de tener su código revisado ¿Alguna sugerencia?

Esto solía ser una pregunta de subversión, pero como muchas personas sugieren usar algo diferente a svn, trataré de seguir esta dirección.

Answer 1

He utilizado PVCS para control de fuente y hace lo que quiere, pero sería un gran cambio para un equipo utilizado para SVN y cuesta dinero, probablemente no valga la pena en general.

Answer 2

Tal vez se beneficie al cambiar a un sistema de control de versiones distribuidas como Git o Bazaar. Debería poder mantener un sistema donde pueda verificar las fusiones en el repositorio principal.

Las herramientas para cada uno no son tan avanzadas como SVN (todavía) pero están bastante bien. Solo algo a considerar.

Answer 3

En Bazaar puede tener un Human GateKeeper en el flujo de trabajo que funcionaría como revisor.

Los comandos en Bazaar son muy similares a los de SVN más funcionalidades adicionales y excelentes (por ejemplo, cambios de estantería, etc.).

Bazaar tiene soporte básico para importar repositorio SVN con historial completo, admite módulos conectables y TortoiseBzr está en proceso. También es posible que desee echar un vistazo a QBzr.

Answer 4

Mi sensación es que este tipo de flujo de trabajo debe rastrearse en su software de seguimiento de errores. Trac, por ejemplo, le permitirá construir flujos de trabajo personalizados para implementar un paso de revisión de código. También tiene un complemento XMLRPC que le permite evitar que las sucursales de tickets se fusionen a menos que su ticket asociado haya progresado al punto correcto en el flujo de trabajo.

Answer 5

No estoy seguro de que haya una forma "ideal" de hacer esto: ¡lo busqué!

Las dos opciones que he utilizado son:

• Una rama por cada cambio. Siempre que tenga una convención de nomenclatura, esto no es tan oneroso como suena inicialmente. Esto se rompe si los cambios a menudo son correcciones de errores muy pequeñas o especialmente características grandes.

• Solución de baja tecnología: revise el código en la computadora de su compañero antes de que él compruebe el código, vea en una unidad compartida o lo que sea apropiado en su entorno.

  opciones

También he considerado como svk, que es una versión distribuida de la subversión, pero no tienen experiencia de utilizarlo.

También es posible sincronizar de svn a git. Esto le permitiría mantener svn y obtener su flujo de trabajo de revisión a expensas de la complejidad. También suena bastante frágil.

Answer 6

¿envían parches a la lista de correo de su proyecto?

Quizás sería una misión desarrollar algo para esto. Uso de dos repositorios y algún software web que combina el código de los repositorios "preafirmar" con los repositorios, cuando se cumplen ciertas pautas.

Answer 7

Code Collaborator (http://www.smartbear.com/codecollab.php) hace todo lo que quiere. Lo usamos con Perforce. La creación de revisiones se realiza fácilmente desde el cliente obligatorio, o desde Eclipse si lo desea. Las revisiones se manejan simplemente con una interfaz web. No tienes que hacer tus propios diffs. Realiza un seguimiento de los defectos por ti.

Lo único que no se puede hacer es evitar físicamente un check-in sin una revisión, pero si no confías en que tus desarrolladores no omitan el sistema por completo, entonces tienes problemas mayores. Además, siempre hay una vez cuando está codificando solo por la noche y TIENE que verificar el código.

Answer 8

Team Foundation Server tiene el concepto de "código de estantería" que esencialmente crea una mini rama que luego puede extraer abajo para su revisión. En ese punto, puede fusionar el código archivado en la rama principal después de la aprobación. También puede configurar los derechos de forma tal que alguien pueda solo código de estantería, y no registrar en la cajuela. A continuación, otorgaría derechos a ciertas personas para poder realizar las fusiones, presumiblemente después del ciclo de revisión adecuado.