¿Hay alguna manera en mercurial de eliminar viejos conjuntos de cambios de una base de datos? Tengo un repositorio de 60GB y eso hace que sea bastante doloroso hacer un clon. Me gustaría recortar todo antes de una fecha determinada y guardar la enorme base de datos para recolectar polvo.Mercurial Eliminar historial
usted puede hacerlo, pero al hacerlo se anulará todos los clones por ahí, por lo que generalmente no es aconsejable hacer a menos que esté trabajando completamente solo.
Cada conjunto de cambios en mercurial se identifica de manera única por un código hash, que es una combinación de (entre otras cosas) los cambios del código fuente, los metadatos y los valores hash de uno o dos elementos principales. Esos padres deben existir en el repositorio desde el inicio del proyecto. (No tener esa restricción sería tener clones superficiales, que no están disponibles (todavía)).
Si estás de acuerdo con el cambio de los valores hash de los conjuntos de cambios más recientes (que a su vez rompe todos los clones que hay en la naturaleza), puede hacerlo con los comandos;
hg export -o 'changeset-%R.patch' 400:tip # changesets 400 through the end for example
cd /elsewhere
hg init newrepo
cd newrepo
hg import /path/to/the/patches/*.patch
Probablemente tendrá que trabajar un poco para manejar los conjuntos de cambios de fusión, pero esa es la idea general.
Uno también podría hacerlo utilizando hg convert con el tipo hg como el origen y los tipos de destino, y usando un splicemap, pero eso es probablemente más complicado aún.
La pregunta más grande es, ¿cómo escribir un máximo de 60 GB de código fuente, o se le agregó archivos generados contra todos los consejos. :)
Respuesta mucho más detallada que mi respuesta (eliminada). +1 – VonC
Estoy importando desde otro sistema de control de fuente un proyecto que incluye binarios generados. Estamos tratando de sacar a los dlls del control de la fuente en este momento. ¡Gracias por la ayuda! –
La respuesta contiene un error tipográfico. El nombre de archivo debe contener% r minúscula (números rellenos cero) de lo contrario los archivos no se procesarán en el orden correcto cuando los importe. – Gili
No hay una manera simple/recomendada de hacerlo directamente a un repositorio existente.
Sin embargo, puede "convertir" a tu repositorio mercurial a una nueva operación de mercurio y elegir una revisión desde donde incluir la historia en adelante a través de la opción convert.hg.startrev
hg convert --config convert.hg.startrev=1234 <source-repository> <new-repository-name>
La nueva operación contendrá todo del repositorio original menos el historial anterior a la revisión inicial.
Advertencia: El nuevo repositorio tendrá ID de conjuntos de cambios completamente nuevos, es decir, no está relacionado con el repositorio original. Después de crear el nuevo repositorio, cada desarrollador debe clonar el nuevo repositorio y eliminar sus clones del repositorio original.
He utilizado este a pases viejos de limpieza de uso interno dentro de nuestra empresa - en combinación con la opción --filemap para eliminar archivos no deseados también.
Entonces, ¿cómo es esa solución diferente de simplemente eliminar el subdirectorio .hg/y hacer hg ¿en eso? – grzaks
Disculpe, no entiendo su comentario. ¿Qué tienen que ver el dir .hg local y un hg init con la eliminación de conjuntos de cambios de un repositorio? –
@Gaks, su enfoque destruye todo el repositorio y crea uno nuevo, el enfoque de Gerd destruye selectivamente el repositorio de una cierta revisión posterior. Ambos enfoques son útiles dependiendo de sus circunstancias. El enfoque de Gerd es útil para mí ahora que estoy a punto de hacer público un repositorio privado y quiero mantener las revisiones del último mes, pero nada antes de eso. – lsh
¿Qué archivos son grandes? – tonfa
¿Cómo se hizo tan grande para empezar? – Santa
Si Jake tiene algún archivo binario (que a veces es necesario ... no todos los archivos binarios son generados por la fuente), cada pequeño cambio en ese archivo da como resultado una nueva copia realizada en el repositorio. Dependiendo del tamaño del archivo o la frecuencia de los cambios, algo así como 60GB podría tardar tanto tiempo. – bobpaul