2012-04-12 32 views
0

我一直在尝试SVN一段时间。为了测试作为SVN管理员和SVN用户的不同方面,我有一个小测试项目。这里先介绍一下。与SVN相关的“干线/分支”概念

我有一个脚本:

<repos>/python/testScript/trunk/testScript.py 

此脚本检查一个环境变量$ LOCALSITE并列出结果。今天,我发现了一个简单的脚本,如果该env。变量未设置。于是我立即分流到:

<repos>/python/testScript/branches/branch-00.01.xx/testScript.py 

,也推一个标签:“失败的情况下,$ LOCALSITE没有设置”

<repos>/python/testScript/tags/0.1.1/testScript.py 

所以这第一个标签仍然是继承的错误就像干线仍然遭受同样的问题。

我推送标签的原因是我%100确定此脚本将在正确设置$ LOCALSITE设置的环境中执行。所以它不会中断。和往常一样,人们可以继续使用“tag-0.1.1”。

但是我仍然想解决这个问题。所以这里是问题:

我已经修复并测试了“branch-00.01.xx/testScript.py”上的问题,所以现在我知道“branch-00.01.xx”正在工作,除非有更多的隐藏错误。那是正确的一步吗?或者我应该修好后备箱?

现在我该怎么办?我应该将固定分支推向新标签吗?或者我应该修复后备箱并杀死分支“branch-00.01.xx”?

谢谢。

回答

0

分支模型假定您完成某个功能的工作后,将合并到主干中。没有必要标记它,因为你不想将它暴露给外部世界。 (事实上​​,你可以直接在主干上做这个修复,但是我明白你正在探索这个过程)。

既然你刚刚开始,我建议你看看mercurial:它的语法很像svn,但它是下一代的“分布式”版本控制。我不是故意说svn,这是一个很棒的系统,但这也是你想知道的。

+0

是的,我想了一会儿,似乎这是我应该做的:修复树干。谢谢。是的,我试图模拟一个svn体验。 – symbolix 2012-04-12 21:33:09

+0

分支也适用于错误修正(或新功能),如果在错误修复完成之前主干可能会更改。当我自己工作时,我只将它们用于主要实验,因为在实验完成之前我可能会对树干进行小修改。如果它失败了,我也要隔离实验,最后放到一边(但可能想要稍后再回来并从中选择)。 – alexis 2012-04-13 09:40:19

0

在某个层次上,选择什么并不重要,因为为方便起见,树干/分支只是逻辑概念(名称),并没有技术差异。

根据我的经验,您通常会考虑使用最新最好的开发工具,而将分支留给已经推送给客户的版本,可能需要稍后处理,但不要担心正在进行中行李箱改变了事情。

0

不同的网站以不同的方式去解决这个问题。很多都是政策问题。

我见过,IMO的最佳方式:

1)Trunk是一种相对自由参加的所有,但也有可能是没有什么可以签入树干而无需首先运行自动化测试的政策。这往往会减少在主干上等待测试无关变化的人员。

2)分支仍在变化,但会逐渐减慢变化。签入干线的东西可能会被评估以检入相关分支。过了一段时间,分支可能会被“冻结”,EG通过设置一个提交钩子来拒绝所有不包含一些魔术饼干的提交。如果有人想要足够严格(通过查看提交历史记录),这很容易解决,但它可以消除冻结分支的意外登录。

3)当一个给定的分支看起来相当稳定时,它会在打包Q/A之前被复制到一个标签。这些标签一旦创建就永远不会改变,作为一个参考点 - 尽管理论上SVN将它们视为同等可变 - 但差异再次是一个政策问题。

所有这些的恼人的部分是SVN外部引用。如果你没有,分支和标签很容易 - 只需svn copy,你就完成了。如果你有它们,你最终会写一个脚本来调整外部引用作为分支/标记过程的一部分。但是有时候外部引用是非常有用的。我一直在尝试在分支期间“内部化”所有外部引用 - IOW将所有外部引用作为新创建分支的一部分进行复制,以保持分支和标记简单。然后开发人员需要在有重要问题的情况下将问题检查到更多的地方,但至少在我个人的项目中,它似乎更多的是帮助而不是阻碍。