Formato de código y diferencias de control de fuente

¿Qué productos de control de origen tienen una function "diff" que ignora el espacio en blanco, llaves, etc., al calcular la diferencia entre las versiones registradas? Me parece recordar que la diferencia de Clearcase hizo esto, pero Visual SourceSafe (o al less la versión que utilicé) no lo hizo.

La razón por la que pregunto es probablemente bastante típica. Cuatro desarrolladores perfectamente razonables en un equipo tienen cuatro forms completamente diferentes de formatear su código. Al revisar el código modificado por otra persona, cada uno ejecutará inmediatamente algún tipo de macro de progtwig o editor para formatear las cosas de la forma que prefiera. Realizan cambios de código reales. Ellos registran sus cambios. Se van de vacaciones. Dos días después, ese progtwig, que había estado funcionando bien durante dos años, explota. El desarrollador asignado al error hace una diferencia entre versiones y encuentra 204 diferencias, de las cuales solo 3 tienen importancia, porque el algorithm diff es cojo.

Sí, puedes tener estándares de encoding. La mayoría de las personas los encuentran terribles. Una solución en la que todos puedan comer su pastel y comerlo también parece mucho más preferible.

=========

EDITAR: Gracias a todos por algunas excelentes sugerencias.

Lo que le quito a esto es:

(1) Se prefiere un sistema de control de fuente con diffs del tipo de plug-in.

(2) Encuentra una diferencia con las opciones adecuadas.

(3) Use un buen progtwig de formatting fuente y establezca un estándar de logging.

Suena como un plan. Gracias de nuevo.

¿Tal vez debería elegir un formatting y ejecutar alguna herramienta de sangría antes de registrarse para que cada persona pueda verificar, volver a formatear a sus preferences, hacer los cambios, volver a formatear el estándar oficial y luego registrarlo?

Un par de pasos adicionales, pero ya usan herramientas de sangría al trabajar. Tal vez puede ser un script de check-in desencadenado?

Editar: esto también podría resolver el problema de la llave.

(No he probado esta solución yo mismo, de ahí los "perhapes" y "maybes", pero he estado en proyectos con los mismos problemas, y es un dolor tratar de pasar por dificultades con cientos de cambios irrelevantes que no son limitado a espacios en blanco, pero incluye el formatting en sí).

Git tiene estas opciones:

  • --ignore-space-at-eol

    Ignore los cambios en el espacio en blanco en EOL.

  • -b, --ignore-space-change

    Ignore los cambios en la cantidad de espacios en blanco. Esto ignora los espacios en blanco al final de la línea, y considera que todas las demás secuencias de uno o más caracteres en espacio en blanco son equivalentes.

  • -w, --ignore-all-space

    Ignora el espacio en blanco al comparar líneas. Esto ignora las diferencias incluso si una línea tiene espacios en blanco donde la otra línea no tiene ninguno.

No estoy seguro de si los cambios de llaves se pueden ignorar usando la diferencia de Git.

Si se trata de un código C / C ++, puede definir reglas Astyle y luego convertir el estilo de corsé del código fuente al que desee, utilizando Astyle . Un git diff producirá una salida sana.

Elija un estándar de encoding (espantoso), escríbalo en algún documento oficial de normas de encoding y continúe con su vida, jugar con el espacio en blanco no es un trabajo productivo.

Y recuerde que usted es un desarrollador profesional, su trabajo es realizar el proyecto, cambiar cualquier cosa en el código debido a una preference de estilo personal daña el proyecto; no solo hará que difijar sea más difícil, sino que también puede presentar problemas difíciles de encontrar. si su formateador de origen o comstackdor tiene errores (y su herramienta de diferencias de fantasía no lo salvará cuando dos compañeros de trabajo comiencen a pelear por la carcasa).

Y si alguien simplemente no acepta trabajar con el estilo seleccionado simplemente recuérdele que está progtwigndo como una profesión y no como un hobby, visite http://www.ericsink.com/entries/No_Great_Hackers.html.

Subversion aparentemente lo admite, ya sea de forma nativa en las últimas versiones, o mediante el uso de un diff alternativo como Gnu Diff.

Beyond Compare lo hace (y mucho más) y puede integrarlo en Subversion o en Sourcesafe como una herramienta de diferencia externa.

Como se explica en ¿Es posible que git-merge ignore las diferencias de final de línea? , es más una cuestión asociar la herramienta diff correcta a tu VCS favorito, en lugar de confiar en la opción VCS correcta (incluso si Git tiene algunas opciones con respecto al espacio en blanco, como la mencionada en la respuesta de Alan , siempre será tan completo como uno quisiera).

DiffMerge es el más completo en esas opciones de "ignorar", ya que no solo puede ignorar espacios sino también otras "variaciones" basadas en el lenguaje de progtwigción utilizado en un file determinado.