我在一个大型项目上工作，其中所有源文件都存储在版本控件中，项目文件除外。这是首席开发人员的决定。他的推理是：
相反，开发人员最初会获得其他开发人员项目文件的副本。然后，当添加新文件时，每个开发人员都会通知所有其他有关更改的内容。从长远来看，这让我感到非常耗时。
在我看来，不跟踪项目文件更改的假设好处被危险所抵消。除了引用其所需的源文件之外，每个项目文件都具有配置设置，如果它们损坏或出现硬件故障，则会非常耗时并且容易出错。其中一些嵌入了源代码，几乎无法恢复。
我试图说服领导他的两个理由都可以通过以下方式完成：
但到目前为止，他不愿意听从我的建议。我检查了svn日志，发现每个主要版本的历史都以Add开头。我觉得他根本不知道如何使用分支功能。
我担心什么，或者我的担忧是否有效？
答案 0 :(得分：4)
您的疑虑是有效的。没有充分的理由从存储库中排除项目文件。他们应该绝对受版本控制。您还需要对自动构建的目录结构进行标准化，因此您的领导只是推迟了不可避免的。
以下是将项目（*。* proj）文件检入版本控制的一些原因：
避免不必要的构建中断。每次添加，删除或重命名源文件时，依赖于各个开发人员通知团队的其他成员不是一种可持续的做法。会有错误，你最终会破坏构建，你的团队将浪费宝贵的时间来确定构建破坏的原因。
维护权威的源配置。如果存储库中没有项目文件，那么您没有足够的信息来可靠地构建解决方案。您的团队是否计划从您的某个开发人员的计算机上提供构建？如果是这样，哪一个？拥有源控制存储库的重点是维护一个权威的源配置，您可以从中构建和发布版本。
简化项目管理。当您引入并非每个人都熟悉的项目类型时，让每个团队成员独立更新各个项目文件的各个副本会变得更加复杂。如果您需要引入WiX项目来生成MSI包或数据库项目，会发生什么？
我还认为，为防止这种不检查项目文件的策略而提出的两点很容易被驳斥。我们来看看每个：
协调开发人员工作目录之间的差异需要花费时间。
应始终使用相对路径设置源配置。如果您的源配置中有硬编码路径（项目文件，资源文件等），那么您做错了。选择忽略这个问题不会让它消失。
它允许开发人员独立工作，直到他们的变化稳定
不，使用版本控制可让开发人员独立工作，直到他们的更改稳定为止。如果每个人都继续维护自己单独的项目文件副本，只要有人检查引用新源文件中的类的更改，就会打破团队中的每个人，直到他们停止他们正在做的事情为止。仔细更新他们的项目文件。将这种体验与源代码控制中的“最新”进行比较。
答案 1 :(得分：0)
通常，从SVN检出的项目应该正常工作，或者应该包含工具以使其工作（例如autogen.sh）。如果缺少项目文件或者您需要了解项目中应该包含哪些文件，那么就会丢失一些内容。
自动生成的文件不应该在SVN中，因为跟踪对这些文件的更改毫无意义。
答案 2 :(得分：0)
具有相对路径的项目文件属于源代码管理。
不支持的文件：例如在.Net中，我不会将.suo（用户选项）web.config（或app.config）放在源代码管理下。您可能让开发人员使用不同的连接字符串等。 / p>
对于web.config，我喜欢放入web.config.example。这样你就可以在初始结账时将文件复制到web.config并调整你想要的设置。如果添加需要添加到所有web.config的内容，则将这些行合并到.example版本中，并通知团队将其合并到其本地版本中。
答案 3 :(得分：0)
我认为这取决于项目的IDE和配置。有些IDE具有硬编码的绝对路径，这对于使用不同本地副本和配置的相同代码的多个开发人员来说是一个真正的问题。避免对库的绝对路径引用，例如，如果可以的话。
在Eclipse（和Java）中，提交.project和.classpath文件（只要类路径没有绝对引用）就可以了。但是，您可能会发现使用Maven等工具可以帮助您从IDE和个人设置中获得一些独立性（在这种情况下，您不需要提交.project，.settings和.classpath自m2eclipse以来Eclipse将自动为您重新创建它们。这可能不适用于其他语言/环境。
另外，如果我需要引用一些非常特定于我的机器的东西（配置或文件位置），它往往在Git中有我自己的本地分支，我在必要时进行rebase，只将公共部分提交到远程存储库。 Git diff / rebase运行良好：即使本地更改影响远程修改的文件，它也可以计算出差异，除非这些更改发生冲突，在这种情况下，您有机会手动合并更改。 / p>
答案 4 :(得分：0)
那只是迟钝了。通过这样的设置，我可以拥有一个完美的工作项目，其中包含与其他人略有不同的文件。想象一下，如果有人意外地将这个混乱传播到QA并且每个人都想弄清楚发生了什么，这会造成严重破坏。想象一下如果它被释放到生产环境就会发生的灾难......！