¿Es una mejor práctica asignar un archivo .sln al control de origen? ¿Cuándo es apropiado o inapropiado hacerlo?¿Debería un .sln comprometerse con el control de origen?
Actualización Hubo varios puntos buenos en las respuestas. Gracias por las respuestas!
Creo que está claro por las otras respuestas que los archivos de la solución son útiles y deben ser confirmados, incluso si no se usan para compilaciones oficiales. Son útiles para cualquiera que use las características de Visual Studio como Ir a Definición/Declaración.
De forma predeterminada, no contienen rutas absolutas ni ningún otro artefacto específico de la máquina. (Desafortunadamente, algunas herramientas complementarias no mantienen adecuadamente esta propiedad, por ejemplo, AMD CodeAnalyst.) Si tiene cuidado de usar rutas relativas en sus archivos de proyecto (tanto C++ como C#), serán independientes de la máquina también.
Probablemente la pregunta más útil es: ¿qué archivos debe excluir? Aquí está el contenido de mi archivo .gitignore para mis proyectos VS 2008:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(. La última entrada es sólo para el generador de perfiles AMD CodeAnalyst)
Para VS 2010, también se debe excluir la siguiente:
ipch/
*.sdf
*.opensdf
También tengo una regla de ignorar los resultados de las pruebas de unidad. Algunas personas pueden registrarlas pero no me gusta el desorden –
+1 - Personalmente, tampoco comprometo nada que se construya, así bin/y obj/ –
Solo confieso archivos .sln que contienen más de 1 proyecto – Justin
Sí, creo que siempre es apropiado. La configuración específica del usuario está en otros archivos.
Definitivamente El .sln tiene referencias a los archivos .prj (proyectos) – dplante
Sí, debes hacer esto. Un archivo de solución contiene solo información sobre la estructura general de su solución. La información es global para la solución y es probable que sea común para todos los desarrolladores en su proyecto.
No contiene ninguna configuración específica del usuario.
Sí, siempre desea incluir el archivo .sln, incluye los enlaces a todos los proyectos que están en la solución.
Lo hacemos porque mantiene todo sincronizado. Todos los proyectos necesarios se encuentran juntos, y nadie tiene que preocuparse por perder uno. Nuestro servidor de compilación (Ant Hill Pro) también usa el sln para determinar qué proyectos crear para una versión.
.slns es lo único que no tenía problemas con en tfs!
Eso es gracioso ... Los SLNs fueron los únicos archivos que he tenido que arreglar ... pero los problemas fueron causados por los desarrolladores que no fueron cuidadosos con las fusiones. –
Sí, debe ser parte del control de fuente. Cuando agregue/elimine proyectos de su aplicación, .sln se actualizaría y sería bueno tenerlo bajo el control de la fuente. Le permitirá extraer las versiones del código de la aplicación 2 y hacer una compilación directamente (si es necesario).
Definitivamente debe tenerlo. Además de las razones que otras personas mencionaron, es necesario hacer una construcción paso a paso de todos los proyectos posibles.
Sí, cosas que debe cometer son:
Cosas que debe no cometer son:
En cuanto a otros archivos generados automáticamente, hay una separate thread.
Tengo que estar en desacuerdo con "cualquier archivo generado automáticamente". –
@Mehrdad ¿Crees que los archivos de Intelisense también deberían estar comprometidos? –
@ Edison: No. Me refiero a los archivos de origen autogenerados como el contexto de datos de LINQ to SQL, por ejemplo. –
El único caso en el que incluso consideraría no almacenarlo en control de código fuente sería si tuviera una solución grande con muchos proyectos en control de fuente, y quisiera crear una pequeña solución con algunos de los proyectos del solución principal para algunos requisitos transitorios privados.
Sí - Todo lo que se utiliza para generar su producto debe estar en control de fuente.
Generalmente, estoy de acuerdo en que los archivos de la solución deben registrarse, sin embargo, en la empresa para la que trabajo hemos hecho algo diferente. Tenemos un repositorio bastante grande y los desarrolladores trabajan en diferentes partes del sistema de vez en cuando. Para apoyar la forma en que trabajamos, tendríamos un archivo de solución grande o varios más pequeños. Ambos tienen algunas deficiencias y requieren trabajo manual en la parte de desarrolladores. Para evitar esto, hemos hecho un complemento que maneja todo eso.
El plug-in permite que cada desarrollador compruebe un subconjunto del árbol de fuentes para trabajar simplemente seleccionando los proyectos relevantes del repositorio. El complemento genera un archivo de solución y modifica los archivos del proyecto sobre la marcha para la solución dada. También maneja referencias. En otras palabras, todo lo que el desarrollador tiene que hacer es seleccionar los proyectos apropiados y luego se generan/modifican los archivos necesarios. Esto también nos permite personalizar otras configuraciones para garantizar los estándares de la compañía.
Además, utilizamos el complemento para admitir varias políticas de check-in, que generalmente impide que los usuarios envíen el código defectuoso/no conforme al repositorio.
Parece que esta podría ser la respuesta a una de mis preguntas sin respuesta (http://stackoverflow.com/questions/1490728/what-are-the-advantages-of-having-projects-in-the-same-solution -si-usas-archivo-r), ¿hay alguna posibilidad de obtener una copia de este complemento? – Benjol
@Benjol: Lo siento, no, es una herramienta interna. Además de las características anteriores, también se integra con una serie de otros sistemas internos, por lo que es muy específico de cómo ejecutamos las cosas. Si solo necesita la parte de solución/proyecto, no es tan difícil de implementar. –
OK, solo una cosa, en su 'gran solución' ¿tiene referencias de proyecto o de archivo? Y si un desarrollador agrega una nueva referencia a un archivo/proyecto, ¿realiza el complemento la conversión adecuada antes de registrarse? ¿Y cómo manejas las dependencias que el desarrollador no ha elegido para pagar? – Benjol
Mantenemos o solucionamos archivos en el Control de versiones TFS. Pero dado que la solución principal es realmente grande, la mayoría de los desarrolladores tienen una solución personal que contiene solo lo que necesitan. El archivo de solución principal es utilizado principalmente por el servidor de compilación.
1) Crear un nuevo proyecto en VS
2) Haga clic derecho sobre la solución en el Explorador de soluciones, seleccione Agregar al control de código fuente
¿Es la sln añadido a control de código fuente? Esa es tu respuesta.
¿Has leído la pregunta? – jlembke
¿Es una buena práctica ponerlo en control de fuente? Las personas que inventaron el ******* aparentemente parecen pensarlo (como lo demostraría mi respuesta), que responde la pregunta por completo. – Will
eres obviamente un apasionado de ... archivos sln ... – jlembke
Por lo general, ponemos todos nuestros archivos de soluciones en un directorio de soluciones. De esta manera, separamos la solución del código un poco, y es más fácil elegir el proyecto en el que necesito trabajar.
En la mayoría de los casos, es una buena idea comprometerse.archivos sln al control de origen.
Si sus archivos .sln son generados por otra herramienta (como CMake), entonces probablemente sea inapropiado ponerlos en control de fuente.
Creo que es el archivo .SUO que NO desea confirmar. – apandit
Solo para el registro, creo que las listas de tareas (si las usa) se almacenan en el archivo .SUO ... Así que, aunque no desee comprometerlas con el control de código fuente, es posible que no desee "simplemente eliminarlas" como crumble extraño. – Benjol