CVS / SVN Historial detallado de compromiso

Recientemente, mi empresa me encargó el análisis de nuestro SVN y (anteriormente) repositorys de CVS para cuantificar la cantidad de "trabajo" (en términos de LOC Deltas) que se realizó en nombre de varios clientes (utilizando los contenidos del logging de compromiso). Para SVN, esto no fue tan malo como para escribir un script simple para algo como esto:

  1. Verifica la sucursal más reciente
  2. Verifique los loggings para determinar la versión anterior
  3. Verifica la versión anterior
  4. Diferencia los dos con alguna herramienta LOC
  5. Repita los pasos 2 a 4

Para CVS, no está tan claro cuáles son los pasos, ya que es difícil saber cuál era la versión anterior y asegurarse de que no sea una twig de desarrollo (que, si se count, daría lugar a un código de doble conteo).

Tengo curiosidad de saber si existen herramientas que hagan esto por mí (en SVN y / o CVS), o que lo simplifiquen. Buscando alnetworkingedor encontré: http://www.networking-bean.com/cvs2cl/ , pero el resultado XML aún no parece resolver el problema de conocer el order de las confirmaciones. Imagino que debe haber alguna biblioteca, ya que http://www.akhphd.au.dk/~bertho/cvsgraph/ requeriría acceso a toda la información que quisiera.

CVS no tenía ningún concepto de parche o compromiso con varios files antes de 2005 (cuando se agregaron 'commitids'). Esto significa que los parches deben ser fabricados en base a otros datos en el repository.

La mejor herramienta disponible para esta fabricación parece ser cvsps , investigará su repository a través de cvs rlog y fabricará una secuencia de confirmaciones (como files de parches) para el repository basado principalmente en la date y hora de las actualizaciones de files.

Otra opción, que puede parecer extraña a primera vista, es convertir el repository CVS a otra herramienta VCS. Todos los actuales pueden parecer que funcionan en un principal de "instantánea" (como lo hizo con SVN). El convertidor hace el "trabajo pesado" de adivinar los compromisos.

Solo como un aparte, espero que su "Herramienta LOC" haga algo sensato con un compromiso que diga "Refactor para mejorar el performance" y tenga un recuento total de MINUS 2000 líneas.