2009-10-27 33 views
32

Mi situación es que un conjunto de archivos se registran en svn, que son muy molestos tener bajo control de código fuente (específicamente un archivo log4j.properties), y me gustaría eliminarlos del control de versiones. Ya sé cómo eliminar un archivo del control de la versión svn en mi propia copia de trabajo local, como en this question y this one, pero eso no es exactamente lo que estoy buscando.¿Cómo elimino un archivo del control de versiones svn sin eliminarlo de cada copia de trabajo?

El problema es que una vez que elimino el archivo con svn rm --keep-local, cuando todos los demás usuarios extraen del repositorio desaparecerán sus copias locales de log4j.properties y sus entornos colapsarán. Lo que quiero hacer es eliminar el archivo del control de versiones en el repositorio, pero también hacerlo de modo que cuando todos los demás extraen del repositorio sea como si hubieran usado --keep-local en sus propias máquinas, de modo que la copia existente de su El archivo log4j.properties se queda pero se convierte en no versionado.

¿Es esto posible? Sospecho que es una característica que svn simplemente no tiene.

+1

Esto es una contradicción Si un archivo es una parte obligatoria del proyecto, si no es así, ¿por qué al eliminarlo se bloquea el entorno de cualquier persona? - pertenece al control de la fuente. –

+2

No es que el archivo no sea necesario, es más un artefacto de implementación que no será el mismo de un usuario a otro; por ejemplo, uno de los archivos contiene un montón de nombres de rutas para los directorios. Ya tenemos archivos de muestra como en la respuesta de Don Kirkby a continuación. –

Respuesta

8

Si realmente tiene muchos de esos archivos, puede matar dos pájaros de un tiro utilizando una operación svndumpfilter. La idea es hacer un volcado del repositorio en el servidor, filtrar los archivos que no desea conservar y cargar el resultado en un nuevo repositorio. Luego pones el nuevo en lugar del anterior.

Esto tiene que hacerse con cuidado, cuando los usuarios no acceden obviamente al repositorio. Pero en realidad eliminará los archivos (interesantes cuando sean grandes) en lugar de mantenerlos en la historia. Como efecto secundario, la próxima vez que un usuario haga una actualización, estos archivos serán ignorados como si nunca estuvieran en el repositorio. Tuvimos que hacer eso varias veces para eliminar los binarios que no tenían su lugar allí.

Link to the related documentation.

ejemplo simple (el comando ofrece una mayor flexibilidad, por supuesto):

svnadmin create repos_new 
svnadmin dump repos | svndumpfilter exclude trunk/log4j.properties | svnadmin load repos_new 

ya que afecta al repositorio en el servidor, quiero subrayar una vez más que usted debe tomar precauciones (mantener su antiguo repositorio). Para archivos no tan molestos, el método propuesto por Don es menos drástico y preferible.

Para evitar este tipo de situación, puede establecer las propiedades svn:ignore correspondientes en los directorios, también puede alentar a las personas a ignorar globalmente (tienen que configurarse en cada cliente desafortunadamente), o incluso usar los scripts de gancho para rechazar de manera preventiva categorías de archivos.

+1

Buena salsa. Esto parece mucho trabajo y peligroso de iniciar (además de que no tengo acceso de shell al repositorio). Pero parece una solución. –

+1

La cantidad de trabajo consiste principalmente en decir qué archivos excluir; puede hacerlo en varios pasos, tal como se explica mejor en el enlace. Una buena noticia es que no tocará el repositorio original, en el peor de los casos tendrá que recrear el nuevo. Mueva el original a otro lugar, cambie el nombre del nuevo como original, verifique que todo esté bien y listo :-) – RedGlyph

7

Lo que suelo hacer en situaciones similares es cambiar el nombre de la copia del repositorio de log4j.properties a log4j.properties.template o log4j.properties.default, y añadir a la lista log4j.propertiessvn:ignore. Luego, cada usuario debe copiar ese archivo al log4j.properties en su copia de trabajo. Para hacerlo un poco más amigable, puede poner un cheque en su script de compilación que imprime un mensaje recordatorio si no encuentra la copia local.

+0

En realidad, tenemos algo muy similar para muchos de estos archivos, y parte de la creación de un entorno nuevo implica la copia de estos archivos. Pero no quiero tener que hacer que todos copien de nuevo los archivos que eliminaré de svn. –

+2

@Tim: a veces el crecimiento requiere un poco de dolor. – NotMe

+1

Sin embargo, la idea del script de compilación es intrigante: supongo que podría escribir un script que copiara automáticamente los archivos de muestra sobre los reales si no existieran, y luego simplemente haga clic y elimine las copias existentes del repositorio. Pero esa es una pregunta diferente ... –

14

El secreto está en asegurarse de que esté en la lista de ignorar antes de que confirme la eliminación. Si lo hace en ese orden, la eliminación no se propagará a las copias de trabajo de los demás.

Todavía estamos usando SVN 1.4 por lo que la opción de --keep-local no está disponible. Pero puede lograr lo mismo borrándolo usando una ruta del servidor y un mensaje de confirmación de m.

Así que en mi ejemplo cometí accidentalmente un directorio llamado nbproject. Ahí es donde se establece el proyecto de desarrollador para el IDE que usamos (NetBeans). ¡No quería borrar eso de las copias de trabajo de todos o perderían todas sus configuraciones! Pero esto hizo el truco. A partir del directorio padre:

$ cd trunk 
$ svn propedit svn:ignore . 

nos lleva a $ EDITOR

añadir nbproject en su propia línea y guardar

$ svn commit -m 'Ignore nbproject' 
$ svn rm https://.../trunk/nbproject -m 'Remove nbproject from svn' 
+3

En realidad, esto no funciona. La eliminación aún se propaga. :( –

+1

tal vez la gente necesita actualizar solo ignorar la configuración antes que nada? – tgkprog

-2
svn delete --keep-local <PATH> 

hará lo

+4

¿No entendiste la pregunta? Se pregunta si hay una alternativa a 'svn delete --keep-local' que no elimine los archivos de los directorios que trabajan de las personas , simplemente quítelos del control de revisión. Por lo tanto, 'svn delete --keep-local' no funcionará. –

Cuestiones relacionadas