您是否将开发/运行时工具放入存储库中？
将开发工具（编译器、IDE、编辑器等）和运行时环境（jre、.net 框架、解释器等）置于版本控制之下有几个很好的理由。 首先，您只需检查存储库即可轻松编译/运行您的程序。 你不需要有任何其他东西。 其次，正如您曾经测试过的那样，三元组肯定是版本兼容的。 然而，它也有其自身的缺点。 主要的一个是必须将大量的大型二进制文件置于版本控制系统之下。 这可能会导致 VCS 变慢并且备份过程更加困难。 你有什么想法？
Putting development tools (compilers, IDEs, editors, ...) and runtime environments (jre, .net framework, interpreters, ...) under the version control has a couple of nice reasons. First, you can easily compile/run your program just by checking out your repository. You don't have to have anything else. Second, the triple is surely version compatible as you once tested it. However, it has its own drawbacks. The main one is the big volume of large binary files that must be put under version control system. That may cause the VCS slower and the backup process harder. What's your idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
绝对用于编译和构建项目的工具和依赖项 - 如果您必须调试问题或开发旧版本的修复程序，并且您已经转向与不太兼容的新版本，那么它非常有用旧的。
IDE 的 & 编辑器不 - 理想情况下，您的项目应该可以从脚本构建，因此这些不是必需的。 无论您使用什么来编辑源，生成的输出仍然应该相同。
Tools and dependencies actually used to compile and build the project, absolutely - it is very useful if you ever have to debug an issue or develop a fix for an older version and you've moved on to newer versions that aren't quite compatible with the old ones.
IDE's & editors no - ideally you're project should be buildable from a script so these would not be necessary. The generated output should still be the same regardless of what you used to edit the source.
我在每个项目根目录中包含一个名为“How-to-get-this-project-running”的文本（因此可以轻松比较）文件，其中包含所有必要的内容，包括正确的 .net 版本和服务包。
I include a text (and thus easily diff-able) file in every project root called "How-to-get-this-project-running" that includes any and all things necessary, including the correct .net version and service packs.
此外，对于专有 IDE（例如 Visual Studio），可能存在许可问题，因为这使得管理谁在使用哪些软件变得困难。
编辑：
我们还用于在源代码管理中存储自动检出源代码（以及所有依赖项）的批处理文件。 开发人员只需查看“Setup”文件夹并运行批处理脚本，而不必在存储库中搜索适当的片段。
Also for proprietry IDE's (e.g. Visual Studio), there can be licensing issues as this makes it difficult to manage who is using which pieces of software.
Edit:
We also used to store batch files that automatically checked out the source code automatically (and all dependencies) in source control. Developers just check out the "Setup" folder and run the batch scripts, instead of having to search the repository for appropriate bits and pieces.
我发现非常好的和常见的（在我有经验的.Net项目中）是将任何“非默认安装”依赖项包含在带有源代码控制的lib或依赖项文件夹中。 运行时由 GAC 提供并且是假设的。
What I find is very nice and common (in .Net projects I have experience with anyway) is including any "non-default install" dependencies in a lib or dependencies folder with source control. The runtime is provided by the GAC and kind of assumed.
事实并非如此：仅获取/复制/签出工具通常是不够的，该工具还必须安装在工作站上。
就我个人而言，我在源版本控制系统中见过库和第三方组件，但没有见过工具。
Not true: it often isn't enough to just get/copy/check out a tool, instead the tool must also be installed on the workstation.
Personally I've seen libraries and 3rd-party components in the source version control system, but not the tools.
我将所有依赖项保存在源代码管理下名为“3rdParty”的文件夹中。 我同意这非常方便，您只需拉下源代码即可开始。 这确实不应该影响源代码控制的性能。
唯一真正的缺点是下拉的初始大小可能相当大。 在我的情况下，任何下载代码的人通常也会运行它，所以没关系。 但如果你期望很多人只是为了阅读而下载源代码，那么这可能会很烦人。
I keep all dependencies in a folder under source control named "3rdParty". I agree that this is very convinient and you can just pull down the source and get going. This really shouldnt affect the performance of the source control.
The only real draw back is that the initial size to pull down can be fairly large. In my situation anyone who pulls downt he code usually will run it also, so it is ok. But if you expect many people to pull down the source just to read then this can be annoying.
我在不止一个工作过的地方看到过这种做法。 在所有情况下，我发现它都非常方便。
I've seen this done in more than one place where I worked. In all cases, I've found it to be pretty convenient.