fusionar una label dispersa en una twig al migrar de cvs a git

Estoy en el process de migrar de cvs a git. (Mofeta si lo desea, pero solo si su empresa ha estado presente por 15 años).

Tengo algunas tags CVS antiguas que solo labeln algunos files en el repository, no todos. Cuando reviso esas tags, parece un repository en el que todo lo que no ha sido labeldo ha sido eliminado. Esa es una diferencia bien conocida en el model de bifurcación entre cvs / svn por un lado y git por el otro.

Me gustaría crear una nueva twig como esta:

  • Comience con mi twig principal y cree una nueva twig de publicación.
  • reemplace solo los files labeldos con tags/A
  • luego además de eso, reemplace solo los files labeldos con tags/B
  • luego cometer todo el lote.

Idealmente, la nueva twig contendría el historial antiguo de los files labeldos y la twig principal.

¿Existe una forma correcta de hacer esto?

 git checkout -b release master git merge --no-commit -s ours tags/A tags/B git checkout tags/A -- . git checkout tags/B -- . git commit # put the above sequence in the commit message if you have love in your heart 

El primer command es "checkout el maestro actual pero como la nueva twig llamada release:".

El segundo es "configurar pero no cometer una fusión no operativa desde tags / A y tags / B". Antes de comprometerse, puede organizar cualquier resultado de fusión que desee.

… en particular, los commands tercero y cuarto cargan las versiones de lo que están en esos dos commits.

¿Puede hacer esto después del hecho, ahora en CVS, para preparar su repository cvs para el script cvs2git? Pase por todas las tags y agregue los files faltantes a la label. cvs tag por sí sola, sin -F no moverá una label. Por lo tanto, puede volver a aplicar la label / A, en function de la label / B, y solo se aplicará a los files que aún no estén labeldos, que es exactamente lo que desea.

Puede resultar que simplemente tenga demasiadas tags para hacer esto práctico. Estoy pensando en 20,000 tags x 5 min / tag = 34 días.

Pero no sé si sería mucho más rápido hacerlo en git. Y una vez que estés en git, tendrás que limpiar todos los artefactos cvs2git: commits de corrección, etc. asociados con cada label. Pero podría imaginar, en teoría, recorrer cada label, revisar más files, agregarlos, modificar la confirmación (con el autor y la date preservados a través de las variables de entorno GIT_ apropiadas), mover la label, compararla con la confirmación anterior que es de hecho en la sucursal en caso de que solo pueda mover la label de return uno.

Además, ¿es importante para usted que sus tags estén en la twig nombrada en la que se supone que deberían estar? Porque con todas esas correcciones confirmadas no lo serán, incluso con tus correcciones. Podría ser práctico garantizar que su twig master se convierta de la manera más elegante y significativa, dejando que algunas de las twigs más antiguas se vuelvan un poco crujientes.

Actualizar

Solo un pensamiento loco. ¿Tendría algún sentido hacer cvs2svn, reparar las tags y luego svn2git? Sé que suena un poco loco, pero la subversión tiene los sets de cambios de git, pero la capacidad de trabajar file por file como cvs, por lo que podría ser el mejor lugar para arreglar las tags.