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