我们当前的开发设置使用单个Subversion存储库，其中包含多个项目，每个项目都包含分支，标记和主干。然后，我们使用“稀疏结账”来选择项目和这些项目的分支，以便与之合作。
结果是工作副本的目录结构与存储库的目录结构相匹配，包括分支信息，我们从不使用svn switch。 （这种工作方式可能对使用SVN的人来说很熟悉，但对于那些不使用SVN的人来说可能会感到惊讶。）
我们正在考虑使用Composer来管理外部和内部依赖关系，但我不确定这如何适用于稀疏结帐工作方式。
我想在现有结帐中使用某个目录以满足依赖关系，而不是每个需要单独副本的“根项目”。
例如：
目前，如果我编辑lib / Bbb / branches / release-1.5中的代码，我可以在两个站点上测试这些更改，而无需提交一个并更新另一个。
有没有办法使用Composer来管理这些依赖项？
（PS：请不要回答“放弃SVN，使用Git，它真是太棒了”;这是对不同问题的回答。）
答案 0 :(得分：2)
不 - 我不相信您可以将Composer作为标准执行此操作：它希望将文件从任何来源（Packagist / VCS / Zips）复制到本地供应商文件夹，这不是您想要的。
那就是说，我相信有两种可能的方法可以使这项工作（至少部分）：
您可以尝试使用composer.json文件中的autoload字段将正确的文件包含到项目中。您仍然需要手动管理相关分支/版本的检出（就像我假设您现在这样做），但您可以通过Composer管理内部库的包含。这可能要求您的库正确命名空间。每个命名空间的文件路径都相对于项目的根目录，但如果需要，可以在根目录下（通过/../路径）。
老实说，如果你已经拥有这些文件的自动加载器，那么这个解决方案可能没什么优势。 Relevant Docs
你也可以编写一个可能管理它的作曲家插件/“自定义安装程序”。这样做的好处是，您可以让它管理检查稀疏存储库的正确部分以获得正确的版本，以及进行正确的Wildstar版本检查，但这将是一个更加困难和风险更大的冒险。
基本过程是你要定义一个新的包类型（例如'internal-svn-package'）。您可以将插件创建为通过Composer正常安装的外部库，Composer声明（通过它的composer.json）它处理这种新类型的包。然后，您的自定义逻辑将用于使用此自定义类型列出的任何包。我不确定您可以重用多少SVN签出的内部编写器逻辑。 Relevant Docs