我正在学习整个版本控制的东西与subversion和使用trunk，分支，标签等我所有不同的工作/版本的项目。我也试图通过与Jenkins的持续集成来加快速度（试过ccnet，这真是个噩梦！）。
所以我的问题是，如果我的项目SVN中有以下区域：
file:///E:/Data/SVN/MyProject/trunk
file:///E:/Data/SVN/MyProject/tags/version_1.0
file:///E:/Data/SVN/MyProject/branch/version_1.1
..在Jenkins中设置此构建项目的最佳做法是什么，以便持续监视SVN中的所有不同区域并构建任何更改？
我是否会设置一个包含多个源代码存储库的项目，每个版本/主干一个？或者我会设置多个构建项目？我该怎么做？
编辑：我是否应该使用矩阵项目（构建多配置项目）？
答案 0 :(得分：6)
对于夜间构建（那些相对不频繁且需要更长时间的构建，通常由于在其中进行更多自动化测试），矩阵项目非常适合。它的主要优点是“一个变化点” - 您不必编辑多个作业，以便在构建中引入相同的更改。这当然只适用于作业在分支之间几乎没有变化的情况（顺便说一下，这种变化通常可以由Run Condition Plugin合理地处理。）
在这种情况下，多配置项目可能不是最适合交付构建的（交付构建在开发人员提交到存储库以检查他/她的更改是否集成良好时运行）。原因在于，如果你提交trunk，你只想构建trunk，但矩阵构建将构建所有东西（消耗计算资源和时间）。
对于交付构建，我将使用参数化构建，其中main参数将是要构建的分支。该构建可以由SVN钩子触发（参见this document）。或者，您可以为每个将轮询分支的分支（通过Subversion plugin）关联触发器构建，并通过Parameterized Trigger plugin使用适当的参数触发主构建。
顺便说一句，我实际上使用了上面提到的所有方法（SVN挂钩除外，我不再出于技术原因而不再这样做。）
答案 1 :(得分：3)
设置多个作业，每个作业对应要构建的每个分支/标记。一旦你找到一份工作，你可以复制它来创建其余的工作，只更改SVN URL。
当你停止维护那些标签/分支时，你也应该摆脱旧的工作，这样你的Jenkins配置就不会失控。