我想执行主要的代码库重组,但我无法继续进行,除非我能提供一种方法,使主干修复程序可以轻松应用于重组之前的分支。
我正在考虑的一种方法是将重组应用于所有支持分支,但这可能会破坏稳定。
首选方法是提供可以考虑更新的文件位置的合并工具。关于如何实现这个的任何建议?
答案 0 :(得分:2)
我的问题是,为什么要将重组合并回分支?分支机构背后的想法是它们(通常)是维护模式(例如,trunk是版本4,你需要返回并修复版本3,你在版本3分支中这样做),或者让人们做一些副作用他们不一定要立刻进入行李箱。
如果您正在对代码库进行完整的重组,那么这似乎是打破代码中某些向后依赖的好时机。如果你不这样做,你可能会限制你实际可以实现的重构。
答案 1 :(得分:1)
我处于相同的情况,其中分支并不总是与维护相关,也不是与修补程序相关。我们经常需要维护多个主动稳定分支,并且必须在它们之间合并。我们没有足够的混合范围来练习在行李箱上进行持续集成。
我们采用更细粒度的方式执行合并。如果移动了文件夹,请直接从一个分支中的旧位置到另一个分支中的新位置执行合并。我还强烈建议您使用“svn move”进行原始重组,确保了解祖先。
无论哪种方式,它都不愉快且非常手动。保持良好的记录。