Nuking huge file in svn repository

Question

Como el zar de la subversión local, les explico a todos que mantengan solo el código fuente y los archivos de texto no grandes en el repositorio, no los enormes archivos de datos binarios. Archivos binarios más pequeños que son parte de las pruebas, tal vez.

Desafortunadamente yo trabajo con seres humanos ! Es probable que alguien contraiga accidentalmente un casco binario de 800MB. Esto ralentiza las operaciones del repositorio.

La última vez que verifiqué, no puede eliminar un archivo del repositorio; solo haz que no sea parte de la última revisión. El repositorio guarda el monstruo para toda la eternidad, en caso de que alguien quiera recordar el estado del repositorio para esa fecha o número de revisión.

¿Hay alguna manera de eliminar realmente ese archivo de monstruos y terminar con un repositorio de un tamaño decente? He intentado el svnadmin volcar/cargar cosa pero fue un dolor.

Answer 1

Alguna información adicional sobre esto se puede encontrar en el blog: Subversion Obliterate, the missing feature

Asegúrese de leer a través de los comentarios también, donde Karl Fogel pone el artículo en perspectiva :-)

Answer 2

Para eliminar permanentemente los archivos monstruo de un repositorio SVN, no hay otra solución que utilizar svnadmin dump/carga. (SVN Book: dump command)

Para evitar que los archivos grandes que se cometa, un script gancho se puede utilizar. Podría tener, por ejemplo, un script que ejecutara "precomprometar" cada vez que alguien intentara comprometerse con el repositorio. La secuencia de comandos podría verificar el tamaño del archivo, o el tipo de archivo, y rechazar la confirmación si contenía un archivo o archivos que eran demasiado grandes o de tipo "prohibido".

Los usos más comunes de los scripts hook son verificar (preconfirmar) que un commit contiene un mensaje de registro, o (post-commit) enviar detalles del commit o actualizar un sitio web con los archivos recientemente comprometidos.

Un script gancho es un script que se ejecuta en respuesta a la respuesta a los eventos del repositorio (SVN Book: Create hooks).

Answer 3

Una vez que haya extraído el archivo de la revisión HEAD, no se ralentiza en la velocidad de operación de los deltas como ony se manejan entre revisiones. (Las copias de seguridad del repositorio deben, por supuesto, manejar la carga).

Answer 4

Si se puede tomar tan pronto como se ha comprometido, la técnica svnadmin dump/carga no es demasiado doloroso. Supongamos que alguien acaba de cometer accidentalmente gormundous-crudo-image.psd en la Revisión 3849. Se podría hacer esto:

svnadmin dump /var/repos -r 1:3848 > ~/repos_dump 

Eso crearía un archivo de volcado contiene todo hasta e incluyendo la revisión 3848. En ese momento, se puede usar svnadmin create y svnadmin load para reconstituir el repositorio sin el compromiso ofensivo, la advertencia es que cualquier cambio que hagas dentro de la estructura del directorio del repositorio -ganchos, enlaces simbólicos, cambios de permisos, archivos de autenticación, etc.- necesitaría ser copiado desde el viejo directorio. He aquí un ejemplo del resto de la sesión de bash puede utilizar para completar la operación:

svnadmin create /var/repos-new 
svnadmin load /var/repos-new < ~/repos_dump 
cp -r /var/repos/conf /var/repos-new 
cp -r /var/repos/hooks /var/repos-new 
mv /var/repos{,-old} && mv /var/repos-new /var/repos 

Estoy seguro que esto será más dolorosa cuanto más historia tiene su repositorio, pero funciona.