版本控制下的项目文件? [英] Project files under version control?
问题描述
我从事一个大型项目，其中除项目文件外，所有源文件都存储在版本控制中.这是首席开发人员的决定.他的理由是:
- 协调开发人员工作目录之间的差异非常耗时.
- 它允许开发人员独立工作，直到他们的更改稳定
相反，开发人员最初会获得其他开发人员的项目文件的副本.然后，当添加新文件时，每个开发人员都会通知所有其他人员有关更改的信息.从长远来看，这让我觉得要花费更多的时间.
在我看来，不跟踪项目文件更改的所谓好处被危险所抵消.除了对其所需源文件的引用之外，每个项目文件都有配置设置，如果它被损坏或出现硬件故障，这些设置将非常耗时且容易出错.其中一些嵌入了几乎不可能恢复的源代码.
我试图说服领导他的两个理由都可以通过以下方式实现:
- 同意标准文件夹结构
- 在项目文件中使用相对路径
- 更有效地使用版本控制系统
但到目前为止，他不愿意听从我的建议.我检查了 svn 日志，发现每个主要版本的历史记录都以 Add 开头.我有一种感觉，他根本不知道如何使用分支功能.
我是什么都不担心还是我的担心有道理?
您的担忧是有道理的.没有充分的理由从存储库中排除项目文件.它们应该绝对处于版本控制之下.您还需要对自动构建的目录结构进行标准化，因此您的领导只是推迟了不可避免的事情.
以下是将项目 (*.*proj) 文件检查到版本控制中的一些原因:
避免不必要的构建中断.每次添加、删除或重命名源文件时，依靠个别开发人员通知团队的其他成员是不可持续的做法.会出现错误，最终构建失败，您的团队将浪费宝贵的时间来尝试确定构建失败的原因.
维护权威的源配置.如果存储库中没有项目文件，则您没有足够的信息来可靠地构建解决方案.您的团队是否计划从您的开发人员的一台机器上交付构建?如果有，是哪一个?拥有源代码控制存储库的全部意义在于维护一个权威的源配置，您可以从中构建和交付版本.
简化项目管理.当您引入并非每个人都熟悉的项目类型时，让每个团队成员独立更新其各个项目文件的个人副本会变得更加复杂.如果需要引入 WiX 项目来生成 MSI 包或数据库项目会怎样?
我还认为，为不签入项目文件的这种策略辩护的两点很容易被反驳.让我们来看看每个:
<块引用><块引用>协调开发人员工作目录之间的差异非常耗时.
源配置应始终使用相对路径进行设置.如果您的源配置(项目文件、资源文件等)中有硬编码路径，那么您就做错了.选择忽略问题并不会让它消失.
<块引用><块引用>它允许开发人员独立工作，直到他们的更改稳定
不，使用版本控制可以让开发人员独立工作，直到他们的更改稳定为止.如果你们每个人继续维护自己单独的项目文件副本，一旦有人签入引用新源文件中的类的更改，您就会破坏团队中的每个人，直到他们停止他们正在做的事情并且仔细更新他们的项目文件.将这种体验与仅从源代码管理中获取最新信息"进行比较.
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?
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:
Its to time consuming to reconcile the differences among developers' working directories.
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.
It allows developers to work independently until their changes are stable
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.
这篇关于版本控制下的项目文件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
