Cómo identificar y eliminar potencialmente grandes compromete binarios dentro de un repositorio SVN?

Question

Estoy trabajando con un repositorio SVN que es más de 3 años de edad, contiene más de 6.100 confirmaciones y es más de 1,5 GB de tamaño. Quiero reducir el tamaño del repositorio SVN. (No estoy hablando sobre el tamaño de una exportación de SVN completa - me refiero a la de depósito completo, ya que existiría en el servidor) antes de pasar a un nuevo servidor

El repositorio actual contiene el código fuente de todos nuestros proyectos de software, pero también contiene relativamente grandes archivos binarios sin importancia, tales como:

• instaladores completas para una serie de herramientas de 3 ª parte.
• .jpg y .png archivos (que son las exportaciones no modificadas del PSD que viven en la misma carpeta).
• BIN y Obj carpetas (que son luego 'svn ignorado' la próxima confirmación).
• directorios ReSharper.

Un número de estos archivos de gran tamaño han sido 'SVN borrado', ya que se han añadido, creando un problema adicional de identifing los mayores infractores.

Quiero ya sea:

• Crea un nuevo repositorio SVN que contiene sólo el código para todos los proyectos de software -. Es realmente importante que los archivos copiados mantienen su historia SVN desde el antiguo repositorio
• Eliminar las grandes confirmaciones y archivos binarios desde el repositorio existente.

¿es alguno de estos posibles?

Answer 1

tendrá que usar svnadmin dump para obtener un archivo de volcado del repositorio actual y posiblemente svndumpfilter para procesar el archivo de volcado. También puede modificar manualmente el archivo de volcado, siempre y cuando usted está cuidado.

Es probable que no va a ser un trabajo rápido y fácil, pero se puede hacer. Yo he hecho algo similar, sólo a un repositorio mucho más pequeño. Yo tenía un acuerdo de recompra con cerca de 150 revisiones que tomó cerca de 600 MB.

Hacer un volcado de su repositorio actual, hacer los cambios necesarios e intenta cargar el volcado modificado en un nuevo repositorio. A continuación, comprobar el nuevo repositorio para asegurarse de que todo se sigue dando sentido (Historia sigue siendo correcta, no hay cambios extraños en las rutas, ...).

Answer 2

Otherside tiene razón sobre svnadmin dump, etc. Algo como esto le conseguirá un puntero en bruto a las revisiones que se añade una gran cantidad de datos a su cesión temporal, y son candidatos para svndumpfilter:

for r in `svn log -q | grep ^r | cut -d ' ' -f 1 | tr -d r`; do
   echo "revision $r is " `svn diff -c $r | wc -c` " bytes";
done

También podría intentar algo como esto para encontrar revisiones que agregan los archivos con una extensión en particular (en este caso, .jpg):

svn log -vq | egrep "^r|\.jpg$" | grep -B 1 "\.jpg$"

Answer 3

Si ha eliminado los archivos del repositorio utilizando "SVN Borrar", que no se elimina realmente los archivos. Esta sería la belleza de la SVN. Una vez que se agrega un archivo al repositorio, que está ahí para siempre (a menos usando descarga y carga). Al "borrar" los archivos, en realidad se crea una nueva revisión que marca la eliminación, pero los archivos siguen existiendo en las revisiones anteriores.

He hecho algunas volcado y carga, pero a un repositorio mucho más grande. Alrededor de 60.000 (!!!) revisiones. Tomó tiempo, pero al final, después de la carga cuidadosa, el repositorio está construido de nuevo.

Su única forma es hacer una lista de las revisiones que se han añadido, modificar y eliminar los archivos. Luego volcar las revisiones en el medio, y cargarlos en el orden correcto. Tenga en cuenta, no hay espacio para errores. Si comete un error, usted tendrá que empezar de nuevo. Volcado y carga desde el principio.

Mi sugerencia, si los archivos de gran tamaño son un problema de este tipo, considerar la creación de un repositorio recién fresca sin antecedentes. Mantener la antigua para la comparación de la historia, y empezar a trabajar de nuevo.

Buena suerte.

Answer 4

Si usted sólo tiene que encontrar las confirmaciones ofensivos y que tienen acceso al servidor que aloja el repositorio: Buscar archivos de gran tamaño en db / revoluciones subdirectorio del repositorio (suponiendo que utiliza el formato fsfs).

Answer 5

¿No es esto sólo un problema diferente, con un paso adicional? Es decir. es necesario localizar los archivos que se tiene en cuenta a ser grandes y binario, y luego comprobar si efectivamente están gestionados por SVN o se han construido localmente (o importados desde el sistema activo paralelo, si ya está en su lugar).

Así, acaba de encontrar los archivos, y luego hacer svn info en ellos para averiguar si son parte del repositorio.

Answer 6

Sólo un pequeño pensamiento, usted dice que el estado actual del repositorio (HEAD y) es bueno, es decir, los grandes archivos binarios han sido SVN delete'ed en el pasado. Por lo tanto, el problema es puramente el tamaño del repositorio?

Sé que dijo que le gustaría mantener toda la historia cometen, sino como una opción, que podría hacer dos depósitos, uno para todo el historial de revisiones, y otro para la revisión HEAD actual.

Si coloca el volcado completo en un DVD, por ejemplo, que tendría los datos disponibles si alguna vez lo necesitaba, pero luego podría eliminar todo el repositorio y SVN cargar el volcado de revisión, dejándole con un pequeño depósito limpio.

También es posible volcar a partir de una revisión específica en adelante, en lugar de sólo la cabeza, así que por ejemplo se podría mantener a los últimos 3 meses de revisiones y volcado todo lo antiguo en un DVD ....

Answer 7

Al explicar la respuesta de Otherside, esto es lo que funcionó para mí en concreto:

svnadmin create new-repo
svnadmin dump old-repo | svndumpfilter exclude --pattern '*.exe' '*.jpg' '*.png' | svnadmin load new-repo

Es posible que pueda excluir sus Obj y Bin directorios mediante su inclusión en el comando svndumpfilter -. Yo no lo probamos

Además, el programa fsfs-stats de Subversion (nuevo en Subversion 1.8, reemplazado por en el 1,9 por svnfsfs stats) podría ser útil para la cuantificación de los tipos de archivos y archivos específicos que se están llenando de seguridad del repositorio.

Esto podría ser útil para la comparación de los repositorios después:

colordiff -u <(svn log -v file:///.../old-repo ) <(svn log -v file:///.../new-repo)