我的团队维护着我们PHP源代码的单个多项目Subversion存储库。我们有一个简单的部署策略，其中应用程序使用的库存储在其目录结构中。这使得可以通过使用tarball或通过检查Subversion之外的代码来进行部署。一切都很好，但是在过去，我曾担任过svn用户的管理员角色，请不要创建嵌套的工作副本或重新排列代码树，尤其是在领先于trunk分支头的工作副本中。
我们有一个更复杂的存储库，但是重要的部分是：
trunk/app4/libs/libB
trunk/lib1
包含LibB是为了说明某些库与部署它们的应用程序一起存储，但是在应用程序之间共享的，积极开发的库则以我们在存储库中的项目级别存储。我们在存储库中的文件树如下所示：
parent_dir/
app4/libs/libB
lib1/
但是对于我们的部署，我们需要像这样构建代码树：
app4/
libs/
lib1
libB
我已经按照以下步骤进行了设置。
＃svn co svn：//svn.example.com/trunk/app4 ./＃cd app4 / libs＃svn co ssvn：//svn.example.com/trunk/lib1
结果是lib1目录未包含在工作副本的app1部分中，从而使app1的状态变得不干净，而是其自身工作副本的根目录。这会使app1工作副本的svn状态变得不干净，因为目录lib1是app4工作副本中的新文件。
＃svn状态
退货
? lib1
通过添加svn可以从app1 / libs添加lib1目录来清除此问题是个好主意吗？可能希望这会将p1 / libs / lib1目录添加到app1的svn信息中，而无需对app1 / libs / lib1 / .svn /进行任何更改，但是我认为这种可能性很小。（TODO：在一个示例中对此进行测试）
最好只是亲自忽略该状态，或者添加libs / lib1忽略以获得干净的状态？还有哪些其他选择？
正确的解决方案是创建2个这样的工作副本。
app4_prj/
app4/
libs/
lib1
lib1_prj
app4/
libs/
lib1
同时：
# cd app4/libs
# svn ignore lib1
在各自的项目中使用lib1和app4进行开发。这样，当每个项目的工作副本中的项目都处于干净状态时，lib1不会在svn中复制，并且您可以更轻松地测试和修改lib，并在继续开发该应用的同时包含其他团队成员的更改，
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句