.sln应该致力于源代码控制吗?

我认为从其他答案中可以清楚地看出,解决方案文件是有用的,应该提交,即使它们不用于官方构建。对于任何使用Visual Studio功能(如Go to Definition/Declaration)的人来说,它们都很方便。

默认情况下,它们不包含绝对路径或任何其他特定于机器的工件。(不幸的是,一些插件工具无法正确维护此属性,例如AMD CodeAnalyst。)如果你在项目文件(C++和C#)中谨慎使用相对路径,它们也将与机器无关。

也许更有用的问题是:你应该排除哪些文件?以下是我的VS 2008项目的.gitignore文件的内容:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(最后一项仅适用于AMD CodeAnalyst分析器。)

对于VS 2010,您还应该排除以下内容:

ipch/
*.sdf
*.opensdf

是的,我认为这总是合适的。用户特定的设置位于其他文件中。

该插件允许每个开发人员只需从存储库中选择相关项目,即可签出源代码树的一个子集进行操作。然后,该插件生成一个解决方案文件,并为给定的解决方案动态修改项目文件。它还处理引用。换句话说,开发人员所要做的就是选择合适的项目,然后生成/修改必要的文件。这也使我们能够定制各种其他设置,以确保公司标准。

是的,你应该承诺的事情是:

• 所有源文件,
• 应用程序配置文件
• 构建脚本

承诺包括:

• 构建生成的文件(例如使用构建脚本) [编辑:] -只有当所有必要的构建脚本和工具都在版本控制下可用时(以确保构建在cvs历史中是真实的)

separate thread

是的,它应该是源代码控制的一部分。

在大多数情况下,将.sln文件提交到源代码管理是一个好主意。

如果你的.sln文件是由其他工具(如CMake)生成的,那么将它们放入源代码管理中可能是不合适的。

我们这样做是因为它使一切保持同步。所有必要的项目都放在一起,没有人需要担心错过一个。我们的构建服务器(Ant Hill Pro)也使用sln来计算要为发布构建哪些项目。

我们通常将所有解决方案文件放在解决方案目录中。通过这种方式,我们将解决方案与代码稍微分开,这样更容易挑选出我需要处理的项目。

你甚至会考虑不将其存储在源代码管理中的唯一情况是,如果你有一个包含许多项目的大型解决方案,并且你想用主解决方案中的一些项目创建一个小型解决方案,以满足一些私人的临时需求。

是的-用于生成产品的所有内容都应该在源代码控制中。

.slns是我们唯一的东西 在tfs中遇到了问题!