svn - 如何提交更改 "in between two revisions"?
svn - How to commit changes "in between two revisions"?
问题:
如何提交更改 "in between two revisions"?
我使用引号是因为很明显你不能在两个修订之间真正提交任何东西——它们已经在存储库中了。
说来话长,即我为什么需要这个?
这个问题一开始可能听起来很尴尬,但这是我在工作中遇到的真实场景。
我们正在向开发分支(或 'feature branches',我们也称它们为 fb)提交开发时更改,工作完成后我们合并到主干。
你知道,基本的工作流程。
从主干我们发布我们的软件,我们同意在实际发布前几天冻结代码。
现在,我愚蠢到相信我们从 trunk 构建的 候选版本 (RC) 是好的,因为在我们实际发布 SW 之前,所有自动化测试都已通过并提交到 trunk 的合并。并删除了功能分支。
假设发布候选版本是修订版 42,而我们发布的 SW 版本是 v1.0.3。因此,r42 是 v1.0.3 版本的 RC。
所以,RC 看起来不错,但在我们发布 SW 之前,我将 r43 提交给主干。 CI 中的所有测试都通过了,所以我删除了分支 fb14(修订版 44)。
结果发现 RC 终究不是很好,需要修复,但是 v1.0.3 一定不能 包含功能 14(在 fb14 中实现),即 r43.
在某种插图形式中也是如此:
==r42=======r43
^ /
| /
| fb14
|
commit fix there to get new RC
所以我需要带回 r42,提交一些东西然后带回 r43。
好的,这很简单,对吧?回滚到 r42:
svn merge -r HEAD:42 .
svn commit -m "Reverted back to RC of v1.0.3"
实施所需的修复并
svn commit -m "Fixed b0rken feature for v1.0.3"
那我们就放出SW我带r43:
svn up
svn merge -c 43 .
但是等等,这没有任何作用!我去了并删除了分支 fb14,所以我需要从 svn 中挖回它并再次将它合并到主干吗?当然,我必须能够以某种方式将 r43 带回来。
所以我有点想要这个:
roll back to r42
-------------
/ \
==r42=====r43=====r45=====r46=====r47
/ \ ^ /
merge/ \ | /
/ \ fix /
fb14 \ /
| -------------
| bring back changes from r43
|
deleted in r44
编辑: 糟糕,他在回答自己的问题!
阅读 https://Whosebug.blog/2011/07/01/its-ok-to-ask-and-answer-your-own-questions/
以后想找这个if/when又遇到类似情况
答案
svn merge -c 43 --ignore-ancestry .
svn commit -m "Introducing feature 14"
已解释
为什么
svn merge -c 43 .
没有在主干中工作?
因为祖先.
假设 r43 中的更改转到文件 foo.cpp
svn merge
记录祖先,这是基本的东西。有了祖先,我们就知道如何追溯到旧版本。对吧?
因此,当提交修订版 43 时,foo.cpp@42 成为了 foo.cpp@43 的祖先。然后我恢复到 r42 并提交 r44,foo.cpp@43 成为 foo.cpp@44.
的祖先
所以,现在在修订版 45 中,我想合并修订版 43。但是我有 foo.cpp@44 从 foo.cpp@42 合并,所以 foo.cpp@43 基本合并到 foo.cpp@45 祖先会被搞砸。
要让 foo.cpp@43 变成 foo.cpp@45,我需要 忽略祖先 。
svn merge -c 43 --ignore-ancestry .
进一步阅读http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.ancestry
当然,通过从地下墓穴中挖掘分支 fb14 并再次合并到主干也可以实现同样的效果:
roll back to r42
----------------
/ \
--r42-----r43-----r45-----r46-----r47
/ ^ /
/ | /
/ fix /
merge fb14--- /
\ merge fb14
delete fb14
即
(修订版 43)
svn merge -r HEAD:42 .
svn commit -m "Reverted back to RC1 of v1.0.3"
您以前从未编码过的代码,我们需要立即修复!
svn commit -m "Fixed b0rken feature for v1.0.3"
启动 CI 机器来构建软件包并发布软件。
svn cp ^/branches/fb14@43 ^/branches/fb14-2
svn up
svn merge --reintegrate ^/branches/fb14-2
svn commit -m "Introducing feature 14"
svn rm ^/branches/fb14-2
但我不喜欢这种方法,所以我阅读了有关高级合并的内容。 ;)
问题:
如何提交更改 "in between two revisions"?
我使用引号是因为很明显你不能在两个修订之间真正提交任何东西——它们已经在存储库中了。
说来话长,即我为什么需要这个?
这个问题一开始可能听起来很尴尬,但这是我在工作中遇到的真实场景。
我们正在向开发分支(或 'feature branches',我们也称它们为 fb)提交开发时更改,工作完成后我们合并到主干。
你知道,基本的工作流程。
从主干我们发布我们的软件,我们同意在实际发布前几天冻结代码。
现在,我愚蠢到相信我们从 trunk 构建的 候选版本 (RC) 是好的,因为在我们实际发布 SW 之前,所有自动化测试都已通过并提交到 trunk 的合并。并删除了功能分支。
假设发布候选版本是修订版 42,而我们发布的 SW 版本是 v1.0.3。因此,r42 是 v1.0.3 版本的 RC。
所以,RC 看起来不错,但在我们发布 SW 之前,我将 r43 提交给主干。 CI 中的所有测试都通过了,所以我删除了分支 fb14(修订版 44)。
结果发现 RC 终究不是很好,需要修复,但是 v1.0.3 一定不能 包含功能 14(在 fb14 中实现),即 r43.
在某种插图形式中也是如此:
==r42=======r43
^ /
| /
| fb14
|
commit fix there to get new RC
所以我需要带回 r42,提交一些东西然后带回 r43。
好的,这很简单,对吧?回滚到 r42:
svn merge -r HEAD:42 .
svn commit -m "Reverted back to RC of v1.0.3"
实施所需的修复并
svn commit -m "Fixed b0rken feature for v1.0.3"
那我们就放出SW我带r43:
svn up
svn merge -c 43 .
但是等等,这没有任何作用!我去了并删除了分支 fb14,所以我需要从 svn 中挖回它并再次将它合并到主干吗?当然,我必须能够以某种方式将 r43 带回来。
所以我有点想要这个:
roll back to r42
-------------
/ \
==r42=====r43=====r45=====r46=====r47
/ \ ^ /
merge/ \ | /
/ \ fix /
fb14 \ /
| -------------
| bring back changes from r43
|
deleted in r44
编辑: 糟糕,他在回答自己的问题!
阅读 https://Whosebug.blog/2011/07/01/its-ok-to-ask-and-answer-your-own-questions/
以后想找这个if/when又遇到类似情况
答案
svn merge -c 43 --ignore-ancestry .
svn commit -m "Introducing feature 14"
已解释
为什么
svn merge -c 43 .
没有在主干中工作?
因为祖先.
假设 r43 中的更改转到文件 foo.cpp
svn merge
记录祖先,这是基本的东西。有了祖先,我们就知道如何追溯到旧版本。对吧?
因此,当提交修订版 43 时,foo.cpp@42 成为了 foo.cpp@43 的祖先。然后我恢复到 r42 并提交 r44,foo.cpp@43 成为 foo.cpp@44.
的祖先
所以,现在在修订版 45 中,我想合并修订版 43。但是我有 foo.cpp@44 从 foo.cpp@42 合并,所以 foo.cpp@43 基本合并到 foo.cpp@45 祖先会被搞砸。
要让 foo.cpp@43 变成 foo.cpp@45,我需要 忽略祖先 。
svn merge -c 43 --ignore-ancestry .
进一步阅读http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.ancestry
当然,通过从地下墓穴中挖掘分支 fb14 并再次合并到主干也可以实现同样的效果:
roll back to r42
----------------
/ \
--r42-----r43-----r45-----r46-----r47
/ ^ /
/ | /
/ fix /
merge fb14--- /
\ merge fb14
delete fb14
即 (修订版 43)
svn merge -r HEAD:42 .
svn commit -m "Reverted back to RC1 of v1.0.3"
您以前从未编码过的代码,我们需要立即修复!
svn commit -m "Fixed b0rken feature for v1.0.3"
启动 CI 机器来构建软件包并发布软件。
svn cp ^/branches/fb14@43 ^/branches/fb14-2
svn up
svn merge --reintegrate ^/branches/fb14-2
svn commit -m "Introducing feature 14"
svn rm ^/branches/fb14-2
但我不喜欢这种方法,所以我阅读了有关高级合并的内容。 ;)