Question

在阅读svnbook之后，我正在尝试清理SVN存储库的结构。 Chapter 4 - Branching & Merging讨论了为多个项目使用trunk，branch和tags布局。

在我的场景中，我为一系列项目维护了多个模块（库，插件和供应商库）。其中没有一个项目使用所有模块，但每个模块至少由一个项目使用。

我可以为每个引用单个模块版本的项目创建分支吗？似乎Complex Tagging就是答案......
我如何使用Complex Tagging作为项目团队的基线？
软件工程检查/修改/提交项目的工作流程是什么？例如，Team Rocket的成员想要为Fred插件添加一个新功能。（见下面的布局）
是否应对模块或项目的功能分支进行初始更改？

最终，我希望看到以下存储库结构：

-Library
| -libFoo
| | -trunk
| | -branch
| | -tags
| |
| -libBar
| | -trunk
| | -branch
| | -tags
| |
| -plugins
|   -pluginFred
|   | -trunk
|   | -branch
|   | -tags
|   | 
|   -pluginBarney
|     -trunk
|     -branch
|     -tags
|
-Projects
  -Galactic
  | -trunk
  | -branch
  | -tags
  |
  -Rocket
    -trunk
    -branch
    -tags

〜问候

Answer 1

我可以为每个引用单个模块版本的项目创建分支吗？

是。

似乎复杂标记就是这个
的答案

它可以回答，但是从我的POV中它将是肮脏的方式。如果您的任何项目必须在其某些模块的某些已知状态 的某些模块中进行SVN版本化，我将更喜欢使用SVN externals（目录类型）externals-sources映射到所需的模块版本。它可以是带有模块标签|分支的URL的无版本定义（不是很好，但可用于可提交分支，可用于RO标记），或PEG-revision用于任何模块的任何 URL

我如何使用复杂标记作为项目团队的基线？

我会建议“不管怎样”。复杂标签作为临时黑客很好，但从历史角度来看很糟糕 - 你将无法重建“在提交之前如何以及从哪个来源创建混合WC”，与所有使用的外部相对于（完全PEG-ged）WC相反模块

软件工程检查/修改/提交项目的工作流程是什么？例如，Team Rocket的成员想要为Fred插件添加一个新功能。

嗯，我最初的反应是“它取决于”，接下来：“太宽泛了”。真的是管理和行政问题，而不是技术和依赖人类而不是技术（并且有很多变化）。简而言之（在理想的美好世界中）：

TR Dev分支pluginFred，修改，测试，合并分支到pluginFred的trunk，再次测试
Team Rocket PM接受这些更改并同意使用修改后的pluginFred
Team Rocket项目中的pluginFred的外部定义（在某些修订版中）已从URL @ OLDREV更改为URL @ NEWREV（或从pluginFred/**/URL1更改为pluginFred/**/URL2）
其他团队也会通过某种方式通知并切换（或不切换）到新版本

团队中（和团队之间）的良好（快速和防弹）沟通是最难的工作。对WIP来说，没有任何粉碎和无PEG的外部因素是混乱和开发者地狱的直接途径

是否应对模块或项目的功能分支进行初始更改？

“这取决于......”来自习惯，ACL，公司规则，存储库树和交叉存储库项目的分离（对于单个整体仓库，您可以随时从任何位置复制到任何位置，交叉回购转移略有更难，但仍然可能）。但共同的“有什么区别？”，如果你有完整的可追溯历史（如果你没有 - 你必须拥有）

多个项目/模块的SVN分支模式

1 个答案: