【发布时间】:2014-02-06 05:14:20
【问题描述】:
我的团队为我们的 PHP 源代码维护一个单一的多项目 subversion 存储库。 我们有一个简单的部署策略,应用程序使用的库存储在它的目录结构中。这使得通过使用 tarball 或通过检查 subversion 中的代码来进行部署成为可能。 这一切都运作良好,但在过去作为管理员角色时,我告诉 svn 用户不要创建嵌套的工作副本或重新排列代码树,尤其是在引导主干分支头部的工作副本中。
我们有一个更复杂的存储库,但重要的部分是:
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 的状态为 unclean,而是它自己的工作副本的根目录。这使得 app1 工作副本的 svn 状态不干净,因为目录 lib1 是 app4 工作副本中的一个新文件。
#svn状态
返回
? lib1
通过添加我可以从 app1/libs 添加 lib1 目录吗?有人可能希望这会将 p1/libs/lib1 目录添加到 app1 的 svn 信息中,而不会对 app1/libs/lib1/.svn/ 进行任何更改,但我认为这不太可能。 (TODO:在一个例子中测试这个)
最好只是亲自忽略该状态,还是添加 libs/lib1 以忽略以获得干净的状态?还有哪些其他选择?
【问题讨论】: