我对Subversion相对较新,希望从更有经验的人那里获得一些见解.我们采取的方法是在主干上进行大量的开发工作(新功能和错误修复),并根据需要将错误修复合并到发布分支中.使用这种方法,开发人员根本不会直接针对发布分支编码,只会合并到它们中.
我的第一个想法是,开发人员可能根本不需要发布分支的工作副本,并且可能会直接在存储库中将对trunk的更改合并到分支中.但我很快就知道Subversion的工作原理并不是这样 - 你需要一个工作副本才能合并.
所以我的下一个想法是,开发人员仍然可以在本地只保留一个代码库副本,将其指向主干,并在需要进行合并时执行svn切换到发布分支.我可以预见几个潜在的问题:
如果我为这个过程组合了一些脚本,我可以防止#1成为一个问题,但是#2更多地关注我.我想知道这是否是这种方法的交易破坏者.
简而言之,我的问题是:当将来自主干的错误修复程序合并到发布分支时,开发人员还没有发布分支的工作副本,对于开发人员来说,将svn切换视为更好的做法要进行合并,还是在本地的其他位置查看发布分支的工作副本？提前致谢!
磁盘空间现在通常很便宜,所以没有理由将所有东西都限制在一个工作副本中 - 单独检查分支可以提供最好的大多数世界(独立于主干开发,更少忘记一个地方的机会,可以很容易如果需要,可以在分支机构上来回切换到中继线上工作,完成后不必重新下载中继线.
我会避免使用svn开关,除非在偶然情况下(如文档中所述)当你开始编写针对一个分支(比如trunk)的解决方案然后得出结论它在自己的分支中会更好(svn copy trunk newbranch; svn)切换newbranch).
你应该总是执行合并到本地工作副本,都让您可以对您的更改进行DIFF你提交之前(你应该在的习惯总是在提交之前做任何承诺),并检查代码编译.
如果发布分支很大并且保留它的本地工作副本很麻烦(如果你有很多发布分支,尤其如此),那么考虑使用分支/补丁管理器 - 指定你的一个程序员管理发布分支,他/她可以选择特定的主干更改以合并到发布分支.大多数人都保存了他们的磁盘使用量,并且您可以更好地控制稳定版本分支.