项目文件受版本控制吗？
我从事一个大型项目，其中除项目文件之外的所有源文件都存储在版本控制中。这是首席开发人员的决定。他的理由是：
- 协调开发人员工作目录之间的差异非常耗时。
- 它允许开发人员独立工作，直到他们的更改稳定为止。
相反，开发人员最初会获得其他开发人员的项目文件的副本。然后，当添加新文件时，每个开发人员都会通知其他所有人员有关更改的信息。从长远来看，这让我觉得更加耗时。
在我看来，不跟踪项目文件的更改所带来的好处被其危险所抵消。除了对其所需源文件的引用之外，每个项目文件还具有配置设置，如果该文件损坏或出现硬件故障，这些配置设置将非常耗时并且容易出错。其中一些嵌入了几乎不可能恢复的源代码。
我试图说服领导，他的两个理由都可以通过以下方式实现：
- 同意标准文件夹结构
- 在项目文件中使用相对路径
- 更有效地使用版本控制系统
但到目前为止，他不愿意听从我的建议。我检查了svn日志，发现每个主要版本的历史记录都以Add开头。我有一种感觉，他根本不知道如何使用分支功能。
我是否无所顾虑，或者我的担忧是否合理？
I work on a large project where all the source files are stored in a version control except the project files. This was the lead developer's decision. His reasoning was:
- Its to time consuming to reconcile the differences among developers' working directories.
- It allows developers to work independently until their changes are stable
Instead, a developer initially gets a copy of a fellow developer's project files. Then when new files are added each developer notifies all the rest about the change. This strikes me as far more time consuming in the long run.
In my opinion the supposed benefits of not tracking changes to the project files are outweighed by the danger. In addition to references to its needed source files each project file has configuration settings that would be very time consuming and error prone to reproduce if it became corrupted or there was a hardware failure. Some of them have source code embedded in them that would be nearly impossible to recover.
I tried to convince the lead that both of his reasons can be accomplished by:
- Agreeing on a standard folder structure
- Using relative paths in the project files
- Using the version control system more effectively
But so far he's unwilling to heed my suggestions. I checked the svn log and discovered that each major version's history begins with an Add. I have a feeling he doesn't know how to use the branching feature at all.
Am I worrying about nothing or are my concerns valid?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你的担忧是有道理的。没有充分的理由从存储库中排除项目文件。它们绝对应该处于版本控制之下。您还需要标准化自动构建的目录结构，因此您的领导只是推迟了不可避免的事情。
以下是将项目 (*.*proj) 文件检查到版本控制中的一些原因：
避免不必要的构建中断。每次添加、删除时，依赖单个开发人员通知团队的其他成员或重命名源文件不是可持续的做法。可能会出现错误，您最终会得到损坏的构建，并且您的团队将浪费宝贵的时间来尝试确定构建损坏的原因。
维护权威的源配置。如果存储库中没有项目文件，则您没有足够的信息来可靠地构建解决方案。您的团队是否计划从您的开发人员的一台机器上交付构建版本？如果有，是哪一个？拥有源代码控制存储库的全部目的是维护权威的源配置，您可以从中构建和交付版本。
简化项目管理。当您引入并非每个人都熟悉的项目类型时，让每个团队成员独立更新各个项目文件的各自副本会变得更加复杂。如果您需要引入 WiX 项目来生成 MSI 包或数据库项目，会发生什么？
我还认为，为捍卫这种不检查项目文件的策略而提出的两点很容易被反驳。让我们分别看一下：
源配置应始终使用相对路径进行设置。如果您的源配置（项目文件、资源文件等）中有硬编码路径，那么您就做错了。选择忽视问题并不会让问题消失。
不，使用版本控制可以让开发人员独立工作，直到他们的更改稳定为止。如果你们每个人都继续维护自己的项目文件的单独副本，那么一旦有人签入引用新源文件中的类的更改，您就会破坏团队中的每个人，直到他们停止正在做的事情并仔细更新他们的项目文件。将这种体验与仅从源代码控制中“获取最新”进行比较。
Your concerns are valid. There's no good reason to exclude project files from the repository. They should absolutely be under version control. You'll need to standardize on a directory structure for automated builds as well, so your lead is just postponing the inevitable.
Here are some reasons to check project (*.*proj) files into version control:
Avoid unnecessary build breaks. Relying on individual developers to notify the rest of the team every time the add, remove or rename a source file is not a sustainable practice. There will be mistakes and you will end up with broken builds and your team will waste valuable time trying to determine why the build broke.
Maintain an authoritative source configuration. If there are no project files in the repository, you don't have enough information there to reliably build the solution. Is your team planning to deliver a build from one of your developer's machines? If so, which one? The whole point of having a source control repository is to maintain an authoritative source configuration from which you build and deliver releases.
Simplify management of your projects. Having each team member independently updating their individual copies of your various project files gets more complicated when you introduce project types that not everyone is familiar with. What happens if you need to introduce a WiX project to generate an MSI package or a Database project?
I'd also argue that the two points made in defense of this strategy of not checking in project files are easily refuted. Let's take a look at each:
Source configurations should always be setup with relative paths. If you have hard coded paths in your source configuration (project files, resource files, etc.) then you're doing it wrong. Choosing to ignore the problem is not going to make it go away.
No, using version control lets developers work in isolation until their changes are stable. If you each continue to maintain your own separate copies of the project files, as soon as someone checks in a change that references a class in a new source file, you've broken everyone on the team until they stop what they're doing and carefully update their project files. Compare that experience with just "getting latest" from source control.
一般来说，从 SVN 签出的项目应该可以工作，或者应该包含使其工作的工具（例如 autogen.sh）。如果项目文件丢失或者您需要了解项目中应包含哪些文件，则说明缺少某些内容。
自动生成的文件不应该在 SVN 中，因为跟踪这些文件的更改是没有意义的。
Generally, a project checked out of SVN should be working, or there should be tools included to make it work (e.g. autogen.sh). If the project file is missing or you need knowledge about which files should be in the project, there is something missing.
Automatically generated files should not be in SVN, as it is pointless to track the changes to these.
具有相对路径的项目文件属于源代码管理。
不这样做的文件：例如在.Net中，我不会将.suo（用户选项）web.config（或app.config置于源代码控制下。您可能有开发人员使用不同的连接字符串等。
在这种情况下web.config，我喜欢放入一个 web.config.example。这样，您可以在初始结帐时将文件复制到 web.config，并调整您想要的设置（如果您添加需要添加到所有网络的内容）。 .config，您将这些行合并到 .example 版本中，并通知团队将其合并到本地版本中。
Project files with relative path belong under source control.
Files that don't: For example in .Net, I would not put the .suo (user options) web.config (or app.config under source control. You may have developers using different connection strings, etc.
In the case of web.config, I like to put a web.config.example in. That way you copy the file to web.config upon initial checkout and tweak what settings you'd like. If you add something that needs to be added to all web.config, you merge those lines into the .example version and notify the team to merge that into their local version.
我认为这取决于IDE和项目的配置。一些 IDE 具有硬编码的绝对路径，对于多个开发人员使用不同的本地副本和配置处理相同的代码来说，这是一个真正的问题。例如，如果可以的话，请避免对库的绝对路径引用。
在 Eclipse（和 Java）中，可以提交
.project和.classpath文件（只要类路径没有绝对引用）。但是，您可能会发现使用 Maven 等工具可以帮助您独立于 IDE 和个人设置（在这种情况下，您不需要提交.project、.settings和 .classpath 在 Eclipse 中，因为 m2eclipse 会自动为您重新创建它们）。这可能不适用于其他语言/环境。此外，如果我需要引用一些真正特定于我的机器的东西（配置或文件位置），它往往在 Git 中拥有我自己的本地分支，我会在必要时对其进行变基，仅将公共部分提交到远程存储库。 Git diff/rebase 效果很好：即使本地更改影响已远程修改的文件，它也往往能够计算出差异，除非这些更改发生冲突，在这种情况下，您有机会手动合并更改。
I think it depends on the IDE and configuration of the project. Some IDEs have hard-coded absolute paths and that's a real problem with multiple developers working on the same code with different local copies and configurations. Avoid absolute path references to libraries, for example, if you can.
In Eclipse (and Java), it's fine to commit
.projectand.classpathfiles (so long as the classpath doesn't have absolute references). However, you may find that using tools like Maven can help having some independence from the IDE and individual settings (in which case you wouldn't need to commit.project,.settingsand.classpathin Eclipse since m2eclipse would re-create them for you automatically). This might not apply as well to other languages/environments.In addition, if I need to reference something really specific to my machine (either configuration or file location), it tend to have my own local branch in Git which I rebase when necessary, committing only the common parts to the remote repository. Git diff/rebase works well: it tends to be able to work out the diffs even if the local changes affect files that have been modified remotely, except when those changes conflict, in which case you get the opportunity to merge the changes manually.
那只是落后了。通过这样的设置，我可以拥有一个完美工作的项目，其中包含与其他人略有不同的文件。想象一下，如果有人不小心将这种混乱传播到质量检查中，并且每个人都试图弄清楚发生了什么，这会造成严重破坏。想象一下，如果它被发布到生产环境，将会发生什么灾难……！
That's just retarded. With a set up like that, I can have a perfectly working project containing files that are subtly different from everyone else. Imagine the havoc this would cause if someone accidentally propagates this mess into QA and everyone is trying to figure out what's going on. Imagine the catastrophe that would ensue if it ever got released to the production environment...!