我之前听说过在源代码控制中包含项目和工作区/解决方案文件通常是不好的做法，但我想获得有关处理这种情况的最佳方法的反馈。
我的工作要求我为我的部门设置源代码控制服务（我从 3 年前的第一天就一直在要求）。我最大的障碍如下。
我们在网络 SMB 共享上保留最新版本的快照，使用标签并手动更新它？可以多人同时维护此工作副本还是该文件夹仅与创建者关联？
我们所有的“项目”文件（包含文件清单、构建信息等）都使用绝对路径。如果我使用 c:\myproject 而同事使用 c:\MaiPrjLolKeke，这真的很痛苦project 通知同事可能需要添加新文件的最佳方式是什么？
【问题讨论】：
标签： svn version-control tortoisesvn
设置您的构建文件以使用相对路径。
理想情况下，您应该能够随时从 SVN 签出副本（并进入任何文件夹），运行构建脚本，运行自动化测试，并立即启动并运行。如果你做不到，那你就做错了。
（是的，您可能还需要首先设置操作系统、数据库服务器、Web 服务器、编程语言和 IDE。但是一旦全球基础设施已经存在，您应该可以点击随时随地从地面运行。）
【讨论】：
如果您的项目中有硬编码路径，那么您需要对其进行标准化，以便大家一起工作。这可能意味着你们都必须改用“c:\work”或“C:\dev”，但要让一切都“正常工作”，这是一个很小的代价。
如果您绝对不能这样做，那么我推荐junction - 这会设置从一个目录到另一个目录的链接。您都可以签入“通用”路径的文件，但仍可以从您自己的首选路径访问它。不是最好的，但可行。
如果您可以使用相对路径，那么您就处于共享工作的天堂。真的尝试一下，因为它会解决你所有的问题。
如果您对必须位于相对于其他项目的特定目录中的引用文件有疑问（例如，位于 c:\include 中的公共集），请将其连接到您签出的位置，假设您可以处理管理所需的纪律，您会没事的。或者您可以使用 svn:externals 将常用文件签出到硬编码路径。
PS。将项目文件放在 SCM 中并不是一个坏习惯，我认为每个人都这样做，但所有路径都必须与项目本身相关，因此您可以在任何您喜欢的地方查看全部内容。
【讨论】：
问题不在于源代码中的项目文件。问题是项目文件中的硬编码路径。
您可以为此使用相对路径或使用环境变量。
例如，您可以为包含文件使用通用“根”，为其他第三方库使用通用“根”。这些根目录下的层次结构应该是相同的。
这通常在我工作过的许多地方使用，通常是您可以指向第三方库的方式。它还解决了在一台机器上拥有一组文件的多个版本的问题。通过更改一个环境变量（在构建脚本或其他方式中），您可以迎合特定目标/构建。
至于您的另一个问题-您在说什么并不完全清楚。我想您是在问是否有多个人签出到同一个共享路径/网络共享。这不是一个好主意。你们都可以拥有自己的源文件工作集/工作副本，并且默认情况下 SVN 不会“锁定”文件，因此您可以同时处理它们。您只需要练习更新/获取最新的源/更改即可。
编辑 - 正如另一位海报所说（我在这里重复一遍，这样你就不会错过它） -
源代码管理中的解决方案和/或项目文件是不错的做法。
编辑：
这是另一种解决方案 - 不确定其他人是否已经提出建议。
在路径结构中创建到其他位置的映射并使其成为网络驱动器 - 例如 x:\
如果每个人都这样做，他们可以保持他们喜欢的目录结构，并且仍然使用相同的项目文件。不需要虚拟的。
例如，如果开发者 A 有
C:\开发\项目\等等 将 X:\project 映射到 c:\development\project
并且开发人员 2 具有： C:\my documents\user\Visual studio\etc...，她将 X:\ 映射到该路径。
维奥拉！
C:\
【讨论】：
我必须处理类似的配置（SVN 存储库中的项目文件。） 主要问题是有人会“修复”他们系统的路径，然后检查更改（这会扼杀其他所有人的项目或强制（邪恶）合并。）
一种可行的解决方案是将模板（例如 TEMPLATE.project）存储在存储库中，并将 (.project) 添加到 SVN:ignore。这允许每个开发人员签出所需文件的模板，但不容易签入意外更改。
解决 .classpath 问题的另一种方法是使用 UserLibraries 来包含所有第三方库。这允许开发人员将它们存储在他们喜欢的任何位置并在 Eclipse 中配置映射。
【讨论】：