Question

我的团队维护着一个PHP源代码的单项多项目subversion存储库。我们有一个简单的部署策略，应用程序使用的库存储在它的目录结构中。这可以通过使用tarball或通过检查subversion中的代码来实现部署。这一切都运行良好，但在过去的管理员角色中，我告诉svn用户不要创建嵌套的工作副本或重新排列代码树，尤其是在引导主干分支头的工作副本中。

我们有一个更复杂的存储库，但重要的部分是：

trunk/app4/libs/libB
trunk/lib1

包含LibB是为了说明一些lib与部署它们的应用程序一起存储，但是在应用程序之间共享的主动开发的lib存储在我们认为是存储库中的项目的级别。如果我们要遵循相同的结构我们在存储库中的工作副本文件树看起来像这样：

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的状态为unclean，但它是它自己的工作副本的根目录。这使得app1工作副本的svn状态不清洁，因为目录lib1是app4工作副本中的新文件。

#svn status

返回

? lib1

通过添加可以从app1 / libs添加lib1目录来清除这个是不是一个好主意？有人可能希望这会将p1 / libs / lib1目录添加到app1的svn info而不对app1 / libs / lib1 / .svn /进行任何更改，但我认为这是不太可能的。（TODO：在一个例子中测试这个）

最好是个人忽略该状态，或者添加libs / lib1以忽略以获得干净的状态？还有什么其他选择？

Answer 1

您无法仅使用工作副本（关于lib1）更改repo-nodes的挂载点。 新存储库（带外部）必须创建并使用

Answer 2

正确的解决方案是创建2个这样的工作副本。

app4_prj/
  app4/
      libs/
        lib1

lib1_prj
  app4/
     libs/
       lib1

两者：

# cd app4/libs 
# svn ignore lib1

在各自的项目中开发lib1和app4。这样当在工作副本中检查每个项目时都处于干净状态，lib1不会在svn中重复，您可以更轻松地测试和修改lib并包括来自其他团队成员的更改，同时继续开发应用程序，

在同一个subversion存储库的工作副本中使用嵌套svn工作副本的最佳方法是什么？

2 个答案: