目前，我在我的供应商目录中签出了一个与Composer一起工作的私有SVN repo。它运行得很好，但前提是我不更改/提交内容。当我在提交对SVN repo的更改后composer update时，我会收到一条明确的消息，即不建议使用我的工作方式，以及消息my.SVN目录丢失。（缺少.svn目录可能是因为我从一个repo中签出了多个供应商包）
我知道在供应商目录中直接结账并不是最好的做法。但它感觉相当舒服（当然，如果它有效的话）。现在，既然我不是一个喜欢坚持不良做法的人，我想在这方面有所改进。
Composer的建议只给了我一些如何在供应商目录中运行SVN的例子，"最佳实践"这句话对我来说也不太清楚。此外，这篇帖子也没有真正的帮助，因为我没有得到Seldaek正在展示的信息。
我的问题是，用SVN管理供应商的正确方法是什么？
建议的方法是只提交composer.lock和composer.json文件。这使您的存储库变得轻量级，因为您不必提交构成所包含库的所有文件。Composer承诺，如果您调用composer install，将安装完全相同的文件。
它的工作方式也是将所有包含的供应商文件实际提交到您的项目存储库中。我在一些项目中这样做是因为除了在存储库中拥有所有内容之外，还没有部署这些内容的方法。好的方面是，每个签出或更新存储库的人都会立即拥有软件的工作副本。糟糕的是，一旦从存储库导出依赖项，就会有一个复杂得多的更新和提交过程，因为您必须手动删除外部存储库的所有符号（如.git目录-如果使用git作为repo，则不希望有git子模块，如果使用SVN，则不想提交完整的git历史记录）-这与从SVN签出的库的方式相同。
如果不创建一个更新脚本来完成将依赖项提交到存储库所需的一切，除非强制执行，否则您永远不会更新软件。如果不提交依赖项，更新就像调用composer update，然后提交composer.json和composer.lock中的更改一样简单。
如果依赖项不在项目存储库中，那么它们是如何部署到生产服务器的？在将文件复制到生产系统之前，请调用composer install。：）