随着我不断上传我的烹饪书的更新版本到厨师服务器，我不得不怀疑烹饪书厨师服务器可以存储的版本数量是否有限制。
这是我应该关注的事情还是没有问题？磁盘空间显然不是我在这里担心的。
答案 0 :(得分：4)
我认为这不是一个很好的答案。我说你不想围绕这个问题设计你的工作流程，并且绝对不希望每次上传都要删除食谱。
定期垃圾收集（一年一次或两次）可能是一个好主意，但它将在很大程度上取决于您如何构建您的菜谱及其依赖关系以及您有多大的压力＆＃39;您正在使用的解算器（gecode或molinillo）。
如果您没有看到缓慢解决问题，那么就没有必要这样做了。如果您看到缓慢解决问题，那么您应该强烈考虑这样做。
如果你有一个大型网站，有数十人为数百本烹饪书做贡献，并且你没有收集旧的垃圾，多年来过时的食谱版本和一些流行的食谱有数百或数千个版本存储在服务器上...考虑它可能是有用的。
如果您只是出发并且主要是您的团队和几十本烹饪书，并且最多只有几十个版本，那么它就不太可能成为问题。
如果你介于两者之间...也许？
ADDED（2016年10月8日）：需要考虑的另一个问题是，有时很多菜谱版本的解决方案变得过于聪明了＃34;选择你已经忘记但却能让它满足所有约束条件的极其古老的食谱版本。我最近遇到了两个有相互冲突限制的食谱（dovecot想要ohai ~> 3.0而chef_nginx需要ohai ~> 4.0）来解决这个问题，depsolver帮我把包装菜谱降级到了一个太老了我的版本我正在使用uw-imapd代替dovecot，它取消了dovecot的ohai约束并使得depsolver感到高兴，同时让我非常伤心，因为Ubuntu现在还没有运送uw-imapd多年。解决这个问题的一种方法是更加明确地将烹饪书限制为带有引脚的最新版本。您也可以简单地将这些未使用的版本从您的厨师服务器中转储出来，这样它们就无法用于解析。
答案 1 :(得分：0)
从单一责任原则的角度来看待你的问题可以得到一个技术性较低的答案＆＃34;
我的意思是：在任何好的系统中，每个组件都应该有一个明确的责任。
现在您可以问问自己：您的厨师服务器是否有责任充当源代码管理工具？
我的意思是：有一些像git，SVN这样的工具，你可以将它命名为仅存在以便对文本文件进行版本管理。
你想让你的厨师服务器也这样做吗？或者对你的＆＃34;配置文本文件进行版本控制是一种更好的策略＆＃34;使用不同的基础设施？！
答案 2 :(得分：0)
所以这取决于您的工作流程。 Chef的生态系统有两个版本约束求解器正在使用：Chef Server总是使用gecode（也称为depsolver），Policyfiles总是使用molinillo，而Berkshelf可以根据配置使用。当你遇到几千个整体版本时，Gecode可能会开始窒息，但这在很大程度上取决于你对良好形成的依赖版本限制有多好。 Molinillo在这方面要好得多，但这意味着使用berks apply来锁定所有环境或使用Policyfiles（即不要让Chef Server尝试针对整个Universe运行约束解决方案）。