代码之家 › 专栏 › 技术社区 › Todd Menier

将错误修复合并到发布分支-SVN切换到分支还是获得单独的工作副本?

branch merge svn

Todd Menier · 技术社区 · 15 年前

我对颠覆比较陌生,希望能从更有经验的人那里得到一些见解。我们正在采取一种方法,在主干上完成大部分开发工作(新特性和错误修复),并根据需要将错误修复合并到发布分支中。使用这种方法,开发人员根本不会直接针对发布分支进行编码,只会合并到它们中。

我的第一个想法是,开发人员可能根本不需要发布分支的工作副本,并且对主干的更改可能直接合并到存储库中的分支中。但我很快就明白了颠覆不是这样的——你需要一个工作副本来合并。

所以我的下一个想法是开发人员仍然可以在本地只保留代码库的一个副本,将其指向主干,并在需要进行合并时执行SVN切换到发布分支。我可以忽略几个潜在的问题:

可能太容易忘记在合并后SVN切换回主干。
开发人员可能对他们的工作副本(他们正在为将来的版本工作的内容,在他们被中断进行错误修复之前)进行了未提交的更改,当他们进行SVN切换时,这些更改仍然存在,并意外地将这些更改合并到发布分支中。

如果我为这个过程编写一些脚本,我就可以防止1成为一个问题,但2更让我担心一点。我想知道这是否会破坏这种方法。

简言之,我的问题是:当从主干到发布分支合并bug修复时,如果开发人员还没有发布分支的工作副本,那么对于开发人员来说,进行SVN切换进行合并,或者在本地的不同位置签出发布分支的工作副本是一种更好的做法吗??提前谢谢!

4 回复 | 直到 15 年前

Amber 15 年前

现在磁盘空间一般都很便宜,所以没有真正的理由把所有的东西都限制在一个工作副本上——单独检查分支会给大多数世界带来最好的结果(独立于主干开发,很少有机会忘记自己的位置,如果需要,可以很容易地从分支工作切换到主干工作,不要完成后必须重新下载中继)。

Ether 15 年前

我将避免使用SVN交换机,除非在偶尔的情况下(如文档中所述),当您开始对一个分支(如Trunk)编码解决方案,然后得出结论,它在自己的分支(SVN copy Trunk Newbranch;SVN switch Newbranch)中会更好。

您应该总是执行合并到本地工作副本中,这样您就可以在提交更改之前对更改执行diff(您应该习惯于总是在提交之前执行,也可以检查代码是否编译。

如果发布分支很大,并且保存一个本地工作副本很麻烦(如果您有很多发布分支正在运行,尤其是这种情况),那么考虑使用分支/补丁管理器-指定一个高级程序员来管理发布分支,他/她可以选择特定的主干更改合并到租赁分公司。大多数人都会将命中的数据保存到他们的磁盘使用中,并且您可以更好地控制稳定的发布分支。

sebasgo 15 年前

这是一个相当哲学的问题。为了避免问题2,我可能会使用单独的签出进行合并。这样做可能需要更长的时间,但肯定更灵活。

sbi 15 年前

我经常使用SVN的稀疏结帐功能。如果我签出一个存储库,我将签出 trunk / tags / releases 非递归文件夹(直接子级,包括文件夹)。然后我进入他们每个人,并更新,以便他们的直系子女也被签出。这样我就可以全面了解整个存储库,而不会浪费太多的磁盘空间。

然后我去完全递归地更新我想工作的内容。如果我已经完成了一些在存储库中不需要删除但在我的磁盘上不再需要的事情,我只需要再次将其更新到直接子对象。

这有明显的优势,可以镜像磁盘上存储库的实际布局。这样很容易导航到某个分支。这种方法的另一个优点是,一个简单的更新将告诉您新的标记和分支。

我还没有遇到一个存储库,其中的标记或分支的数量是如此巨大,以至于只需检查文件夹就不会递归地浪费空间。