Encapsulando cambios de código "propuesto" en un file para su uso con windiff (para la revisión del código)

He visto que esto se usa en grandes compañías de software donde tenían su propio sistema para implementar esto. El desarrollador que quería hacer un checkin primero crearía un "package" autoextraíble que otros desarrolladores podrían abrir en sus sistemas y verían cuáles serían los cambios en el sistema (teniendo en count la versión "base" del file de código + los cambios propuestos). [Piensa en un file portátil que muestre versiones ricas de lo que planeas cometer]

De esta forma, otros desarrolladores podrían ver los cambios de código propuestos, revisarlos / sugerir cambios, etc.

No puedo encontrar algo como esto en el mundo del código abierto. ¿Pueden las personas sugerir algo aquí?

Si está utilizando Subversion , entonces tiene un par de opciones:

  1. Realice los cambios en una sucursal , haga que las personas revisen el logging de esa sucursal y decida sobre una estrategia de fusión.
  2. Si no realiza grandes cambios, no se comprometa: cree un file de parche que pueda enviar a sus colegas. Pueden aplicar ese parche a una copy de trabajo y revisar los cambios realizados antes de comprometerse. Este es el enfoque típico para contribuir a los proyectos de código abierto cuando no eres un committer en el proyecto.

un DVCS (Git o Mercurial) está bastante adaptado a ese escenario en que:

  • el desarrollador puede hacer todos los commits que quiera en el repository local
  • otro desarrollador solo puede get (no fusionar) los cambios del repository del primer desarrollador y compararlos (como por ejemplo en la pregunta " Cómo ver la diferencia de un proyecto github bifurcado ").

Incluso si no se puede get una búsqueda, el primer desarrollador puede generar parches que luego se pueden examinar, como el "package" que describe en la pregunta.
En realidad, la página man del git format-patch menciona:

–no-binary

No muestre los contenidos de los cambios en los files binarys, en su lugar muestre un aviso de que esos files han cambiado. Los parches generados con esta opción no pueden aplicarse correctamente, pero siguen siendo útiles para la revisión del código.

Eso confirma el uso de esos parches para la revisión del código.

Un proyecto de código abierto que puede usar ese tipo de parches sería Review Board .
Gerrit también tiene un mecanismo similar al ilustrado en el process de revisión de Egit .

Si no eres muy particular acerca de un tarball autoextraíble. Aquí hay una revisión rápida de las herramientas de código abierto disponibles.

http://ostatic.com/blog/open-source-code-review-tools

Uso reviewboard y su última versión es bastante buena.