SVN: Ignorando un archivo ya comprometido

Question

Tengo un archivo de configuración que está bajo control de versión usando subversion. Todos tienen su propia copia de este archivo, y necesito que esto no se comprometa nunca. Sin embargo, como dije, ya hay una copia bajo control de versión. Mi pregunta es: ¿cómo elimino este archivo del control de versión sin eliminar el archivo de todos, y luego lo agregué a la lista de ignorar para que no se confirme? Estoy usando la línea de comandos de linux svn.

Answer 1

Realice una comprobación limpia, svn delete el archivo y añada la opción ignorar. Entonces comete esto. Todos los demás tendrán que tener cuidado (una vez) de que su copia local no se elimine en el siguiente svn update, pero después de eso, el archivo local se mantendrá sin ser molestado e ignorado por SVN.

Answer 2

Si elimina el archivo del control de versión, ¿cómo lo obtiene un desarrollador nuevo en el proyecto (o el que accidentalmente borró su copia local) después del pago inicial? ¿Qué pasa si hay adiciones al archivo de configuración?

Yo sugeriría lo siguiente: Mantener un archivo de configuración por defecto (sin contraseñas, nombres de host, las cadenas de conexión, etc.) en SVN, nombre algo así como settings.dist, y dejar que el código funcione con una copia de este, llamado settings . Cada desarrollador tiene que hacer esta copia una vez, y luego puede trabajar con su configuración personalizada. Si hay adiciones, agréguelas al settings.dist; todos los demás recibirán una actualización y podrán fusionarlas en su copia personalizada.

Answer 3

simplemente defina un archivo que contenga configuraciones que anularán las predeterminadas. Este archivo no está registrado en Subversion y cada desarrollador es responsable de mantener este archivo de acuerdo con sus entornos.

En un mundo basado en Ant, que tendría los archivos:

settings.properties 
settings-local.properties (ignored for Subversion) 

y en su archivo

<property file="settings-local.properties"/> 
<property file="settings.properties"/> 

build.xml Para aquellos que no pudieron conectar los puntos:

1. modificar el archivo build.xml como propuesto
2. s y los setting-local.properties como ignorados
3. en un objetivo init de su construcción, copiar los settings.properties a settings-local.properties
4. esperar un par de días hasta que todos hayan tenido la oportunidad de ejecutar este objetivo
5. eliminar los setting.properties de la subversión

Voila, cada desarrollador tiene sus propias setting-local.properties y todo se realiza de forma automática (y ningún desarrollador perdido su configuración, lo que ocurre si brutalmente elimina el archivo de Suvbersion y no hay "Todos los demás tendrán que cuidarse ...")

Answer 4

[[Soy nuevo en subversión, así que tal vez esto no tenga sentido. marcando esto como wiki: si conoce la respuesta correcta, por favor, APÉNDESE en la sección posterior]]

¿No podría tener un conjunto personalizado de pasos de verificación para que cada usuario obtenga una carpeta de configuración diferente?

$ svn checkout http://example.com/project project 
.. 
$ dir project 
original_settings\  folder1\  folder2\ 
$ svn checkout http://example.com/project/aaron_settings project\settings 
.. 
$ dir project 
original_settings\  folder1\  folder2\ settings\ 

O para los nuevos usuarios

$ svn import project\settings http://example.com/project/aaron_settings 

Lo que estoy recibiendo es que desea que cada usuario tiene una vista personalizada del repositorio. En otros sistemas de control de versiones, podría configurar una lista personalizada de los proyectos que estaba usando, los que no era y los lugares extraños.

¿Funciona esto en subversión? El código anterior parece realmente arriesgado, pero tal vez lo estoy haciendo mal.

WIKI:

(nada aún)

Answer 5

Después de eliminar el archivo, los usuarios tendrán que recuperar el archivo desde el repositorio usando svn export.

$ svn export -r x path ./ 

Dónde x es una revisión, donde existía el archivo antes de que se ha eliminado, path es la ruta completa al archivo, y ./ es donde se colocará el archivo.

Consulte svn help export para obtener más información.

Answer 6

Tengo un problema similar. En mi caso, es un archivo de configuración de usuario generado automáticamente (estudio visual) que se ha registrado accidentalmente desde el principio del proyecto. Si bien eliminarlo podría funcionar, parece que es más correct que se elimine del historial, ya que nunca se suponía que debía estar allí en primer lugar.

me encontré con este, lo que podría ser una característica nueva ya que esta cuestión fue publicada originalmente hace 7,5 años:

https://stackoverflow.com/a/6025750/779130

parece una idea sería:

1) create a dump of the project. 
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s). 
3) load the dump as a new project. 

Este podría ser la única forma de deshacerse por completo del archivo. En la mayoría de los casos, el enfoque "eliminar e ignorar" podría ser lo suficientemente bueno.