Agregar files no versionados a subversión

¿Es posible agregar files a subversión que se supone que no debe ser versionada? F.ex. config-files que necesita ser editado para que coincida con cada entorno individual. Cuando un nuevo progtwigdor está conectado al proyecto, debe get el file original de la subversión, pero no se lo comprometerá después de que lo edite y no se sobrescribirá cuando lo actualice.

¿Tal vez la creación de una label para todo el proyecto original es la solución? ¿Primero descargando la label y luego actualizando desde trunk?

¿Algunas ideas?


Aclaración a los comentarios a continuación: El proyecto (Sitecore) consta de aproximadamente 30k cantidad de files diferentes. Necesitamos versionar alnetworkingedor de 100 de estos. Si deberíamos include todos los files en el control de versiones, entonces cada confirmación tardará una eternidad (a medida que la tortuga busca en todas las carpetas). Hoy creamos un file zip que contiene todas las carpetas no versionadas, establece las carpetas como ignorar en svn y luego agrega el zip. El problema es cuando tenemos que cambiar uno o más de los files en el file zip, entonces tenemos que enviar un nuevo ~ 1GB-zip al repository.

Colocaba los files no versionados en una web o server de files accesible para todos los que usaban el proyecto, y agregaba una secuencia de commands para download automáticamente los files (con cremallera si fuera necesario) y extraerlos a las carpetas svnignonetworking para que no son recogidos por subversión.

Si le preocupa que estos files cambien, entonces: ¿no deberían tener versiones?

svn: los externos también pueden ser útiles en esta situación. Creo que pueden configurarse para ser ignorados fácilmente según las circunstancias lo permitan.

En algunos casos, ni siquiera es necesario crear un web.config por desarrollador, ya que el formatting de configuration .Net permite anular secciones específicas de su file de configuration a través del atributo configSource.

El atributo configSource especifica un nombre de file que (cuando el file existe) anula el bloque especificado y, cuando no existe, el bloque se usa tal cual.

 <?xml version="1.0"?> <configuration> <connectionStrings configSource="connections.config"> <add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" /> </connectionStrings> </configuration> 

En el sistema de desarrollador puede simplemente agregar un connections.config con las conexiones para él, mientras que el rest de la configuration se puede compartir.

(Así que esto no resuelve el problema de las templates, pero puede ayudarlo a administrar una plantilla grande como muchas pequeñas)

Crearía una secuencia de commands que genera los files de configuration cuando se ejecuta. De esta forma, no necesita preocuparse porque su SCM se interponga en el path.

Debes volver a pensar cómo estás usando subverion. Subversion almacena información de versión sobre files; ni mas ni less. No puede almacenar files no versionados en subversión; no tiene ningún sentido. Almacenar un zip de 1GB en subversión tampoco va a hacer nada bien.

Debería search una forma en que los desarrolladores puedan anular las configuraciones en estos files a través de files de configuration personalizados en el directory de inicio del usuario o quizás variables de entorno.

Solo usa un file de plantilla para esto. Supongamos que su file se llama config.txt. Mire el file e inserte algunos marcadores donde debería ir la configuration local, cámbiele el nombre a configTemplate.txt y confírmelo. Luego, cada desarrollador debe verificar el file, hacer una copy, eliminar la parte de la plantilla del nombre del file (para que todos obtengan el config.txt correcto) y agregar el nuevo file a la list de ignorar. Luego, o bien permita que todos simplemente editen manualmente en la configuration local donde están los marcadores en el file de plantilla o utilicen un script para hacerlo por ellos (si es posible).

El file de plantilla nunca cambia (a less que haya una diferencia en el formatting del file de configuration, por supuesto).

En respuesta a su edición (y comentario):

Es probable que todas las imágenes, documentos y files binarys que no se generan automáticamente se pongan bajo control de versión. O al less no veo ninguna buena razón para mantenerlos sin versión.

Deje que cada progtwigdor trabaje en su propia twig y permítales fusionar sus cambios nuevamente en la twig principal / troncal. Por supuesto, los compañeros de equipo deben estar a la altura usando el control de versiones y poder usar algo más que solo pagar, actualizar y comprometer.