135

Al evaluar Visual Studio 2010 Beta 2, veo que en el directorio convertido, mis archivos vcproj se convirtieron en vcxproj. También hay vcxproj.filter archivos junto a cada proyecto que parecen contener una descripción de la estructura de la carpeta (\ Archivos de origen, \ Archivos de encabezado, etc.).¿Debo agregar archivos .vcxproj.filter al control de código fuente?

¿Cree que estos archivos de filtro deben mantenerse por usuario, o deben compartirse en todo el grupo de desarrollo y registrarse en SCC?

Mi pensamiento actual es comprobar en ellos, pero me pregunto si hay alguna razón para no hacer eso, o tal vez buenas razones por las que definitivamente ellos tienen que registrarse.

La ventaja obvia es que las estructuras de carpetas coincidirá si estoy mirando la máquina de otra persona, pero tal vez les gustaría reorganizar las cosas lógicamente?

Respuesta

49

Las versiones anteriores de Visual Studio (al menos las versiones 6.0 y 2008) almacenan esa información en su propio archivo de proyecto (archivos .dsp y .vcproj respectivamente), lo que por supuesto es bueno agregar a SCC.

No puedo pensar en ninguna razón para que no incluya estos archivos .Filter en SCC

+0

Estoy contigo. Lo revisé. ¡Gracias! – jschroedl

90

Sacamos intencionadamente la .Filter. archivo de información de .vcproj cuando traducimos al formato .vcxproj MSBuild. Una razón es exactamente lo que señaló, que los filtros son puramente una vista lógica, y diferentes miembros del equipo pueden querer vistas diferentes. La otra es que a veces la compilación está configurada para verificar la marca de tiempo del archivo de proyecto y desencadenar una reconstrucción si ha cambiado, porque eso puede significar que hay diferentes archivos fuente para compilar, o configuraciones diferentes, etc. No lo hago Recuerdo si realizamos el envío con la generación activada de esa manera, pero la idea era que no deseábamos desencadenar una reconstrucción simplemente porque los filtros habían cambiado, ya que no afectaban a la compilación.

+1

para reconstrucciones automáticas, compila si * cualquier * archivo ha cambiado (por ejemplo, fuente), por lo que ahora no ha cambiado nada, excepto que tenemos otro archivo para administrar. – gbjbaanb

+0

Terminamos registrándolos y estamos contentos con ese arreglo hasta el momento. Resulta mejor para nosotros trabajar con otros desarrolladores si tienen la misma estructura de filtro. – jschroedl

+2

en otras palabras, puede administrar ambos archivos como si fueran uno. No creo que nadie más los trate por separado tampoco. Es una buena idea, pero un poco de pensamiento sobre las prácticas del mundo real habría sido muy útil (como poner el tiempo de ejecución en WinSxS) – gbjbaanb

3

Acabo de encontrar que si usa Git puede marcar los archivos .filter para que sean tratados como una unión para fusionarlos para hacerlo más simple. Simplemente agregue la línea:

*.vcxproj.filters merge=union 

a su archivo .gitattributes.

Ver Using .gitattributes to avoid merge conflicts para más detalles.

+0

El enlace mencionado no dice que este archivo .filters debe tener "unión" mencionada en el archivo gitattributes. – ollydbg23

Cuestiones relacionadas