存储库布局和稀疏检出

我的团队正在考虑从ClearCase的转移到Subversion和我们正在考虑举办这样的存储库：存储库布局和稀疏检出

\trunk\project1 
\trunk\project2 
\trunk\project3 

\trunk\staticlib1 
\trunk\staticlib2 
\trunk\staticlib3 

\branches\.. 
\tags\..

这里的问题是，我们有很多的项目（1000+）并且每个项目都是链接到几个常见静态库中的dll。因此，检查中继线中的所有内容都是非启动器，因为它会花费太长的时间（〜2 GB），并且对于分支而言很难实现。

使用svn：externals为每个项目提取相关文件夹似乎并不理想，因为它会生成多个工作副本 - 一个用于项目，一个用于每个静态库文件夹。如果更改跨越项目和一些静态库，我们也无法进行原子提交。

稀疏结帐听起来非常适合这一点，因为我们可以编写一个脚本来只提取所需的目录。但是，当我们想要将分支中的更改合并回主干时，我们需要先检查完整主干。

不知道是否对1）更好的存储库组织或者2）将分支更改合并到稀疏主干工作副本的方法？

来源

2010-04-13 Ying

我不会放弃那种快速的外部。他们也有优势，您可以为特定的项目标签绑定特定的分支/标签。从可重复地构建旧版本中拿出一些地狱。 – sbi 2010-04-13 16:08:59

嗯挂钩对我们来说不会那么有用，因为开发任务通常会涉及项目和其中一些相关静态库的更改。 – Ying 2010-04-13 16:24:01

虽然外部本身很难自动标记。如果project1有staticlib1的头部外部，你不能只标记project1，你还必须知道把staticlib1放到同一个标记中（假设外部是相对的），或者单独标记它并修改外部（假设它是绝对的）。如果这是解决的，外部是伟大的。 – Eugene 2010-04-13 16:28:48

关于＃2

即使是可以执行与稀疏检出合并，我不会推荐。在不完整或浅的工作副本中执行的合并会导致创建子树mergeinfo。 Subtree mergeinfo随着时间的推移会变得非常麻烦。

请参见：Where Did That Mergeinfo Come From?

我建议总是从源分支的根合并到目标分支的完整，整洁的工作拷贝的根。在解决了任何冲突并完成了其他必要的验证之后，我将从该工作副本的根目录提交。

如果您是Subversion的新手，我强烈建议您阅读重新集成的分支机构，反思性合并以及mergeinfo如何工作。 Submerged blog有很多很好的信息，svn book也是如此。

来源

2010-04-13 16:53:11

存储库布局和稀疏检出

回答

相关问题