Importar historial de files y carpetas renombrados al control de versiones

Tengo un cliente que me contrató para implementar el control de versiones usando Mercurial, para su aplicación de quince años. Pero también quiere tener todo el historial cargado en el server Mercurial, pero actualmente no hay un software de control de versiones, solo files renombrados con la date en que fueron cambiados, como program1.c to program1_20060917.c y program1 copy (1) .c, y carpetas viejas con todos los files (otra versión), como folder_20080419.

Pensé en importar file por file como un cambio, pero el recuento supera los 2K commits, y él no lo quiere así.

Astring reconciliarse para agrupar los files en cambios, pero no pude encontrar algo para hacerlo.

Tal vez si pudiera cargar en SVN, Git o CVS, entonces podría convertirlo a Mercurial.

¿Alguien sabe qué se puede usar o hacer? Gracias por adelantado.

Acepta conciliar para agrupar los files en cambios pero no pude encontrar algo para hacerlo

En cualquier caso, la etapa preliminar de esta tarea es solo trabajo manual puro : con solo (por ejemplo) tres estados S1, S2, S3 sin información adicional, no es posible crear un DAG correcto – es S1 -> S2 -> S3 o S1 – > S3 -> S2 o …

Tienes que haber orderado (cronológicamente) la list de cambios. Cada cambio puede ser la carpeta completa o solo file (s).

El set más antiguo será el primer set de cambios en el repository.

Para cada próximo set de cambios que tenga: en el caso o files individuales, copie en el repository, tenga cuidado con los files separados renombrados (cuando agrega un file renombrado junto con el original ya existente, obtendrá días malos para restaurar), se crean segmentos de carpetas más manejable en este aspecto; en el caso de la carpeta completa, elimine todo el contenido anterior del directory de trabajo (todos excepto el directory .hg ) y agregue uno nuevo de la carpeta changeset-folder

Después del reemploop (ambos types) hg status -A le mostrará el estado del directory de trabajo con sus cambios ( M puro no requerirá trucos adicionales, M + A probablemente también – consulte con el autor, la combinación de A + D puede ser el resultado de cambiar el nombre y debe manejarse con precisión)

hg addremove --dry-run intentará recostackr (y mostrar) los cambios en este set de cambios, en comparación con los anteriores (agregar nuevos, olvidar eliminados). En caso de cambio de nombre de algunos files versionados, debe reparar esta información usando la opción -s de addremove, para edición y cambio de nombre simultáneos: seleccionando el porcentaje de similitud (parámetro de la opción -s) a mano para get resultados correctos

Como resultado del set para hg addremove (operaciones reales, sin sin –dry-run) obtendrás el directory operativo, listo para hg commit y el process de repetición con el próximo set de cambios hasta su completa fijación

PD : SVN no te ayudará con los renders en absoluto (los renombrados aún son puntos débiles de Subversion), Git es una opción mucho peor que Mercurial – en Mercurial puedes manejar y arreglar la lógica en caso de errores para addremove -s , Git realiza todo a ciegas detrás de la escena (y en el momento del compromiso, en caso de error, tendrás que arreglar el historial)