需要有关使用分支和合并回主干的帮助/建议
我的问题是，在按照以下过程合并时，在最佳实践场景中，过程的最后一步“将分支折叠回主干”是否是执行此操作的正确方法？
我已经使用 svn 很多年了。在我的个人项目中，我总是不假思索地愉快地在主干上进行修改，并且在很长一段时间内以单行线性方式进行版本控制已经接近完美。简单高效。一切都很幸福，直到有一天我想要对第 3 方库有更多的控制。
今天，我正在进行一个项目，我认为该项目已经超出了直接从主干进行黑客攻击的方法。我有多个第 3 方库，其中一些每周都会更改，我确实需要对其中的内容进行更多控制。我需要能够查看第 3 方库版本之间的特定变更集并跟踪我对特定库所做的更改。我见过几次代码库变得非常混乱，并且很难让缺乏经验的构建大师恢复到可工作的状态，我不能在时间上在这里出错。
所以我研究了供应商分支，到处阅读了一些文章。我有一本很棒的《Version Control with Subversion》一书，但我看到的例子有时在方法上是矛盾的，我想理解“分支”的意义。我即将遵循对此给出的方法埃文·韦弗 (Evan Weaver) 发表的文章。
我列出了下面的过程，我关心的是最后一节“将树枝折叠到树干中”。看来我过去合作过的构建大师通常会将分支变更集“合并”到主干上，而且我认为分支甚至没有被删除。这是正确的方法吗？
创建分支
1 - 记下当前的头版本：
svn info svn://server.com/svn/repository/trunk | grep Revision
2 - 将主干的干净远程副本复制到分支文件夹中。给它起个名字。我们将其称为 your_branch，将 HEAD_REVISION 替换为您在步骤 1 中记下的修订号。
svn cp svn://server.com/svn/repository/trunk \
svn://server.com/svn/repository/branches/your_branch \
-m "Branching from trunk to your_branch at HEAD_REVISION"
： 3 - 切换您的本地结帐以指向新分支（这不会覆盖您的更改）：
svn switch --relocate \
svn://server.com/svn/repository/trunk \
svn://server.com/svn/repository/branches/your_branch
4 - 检查您的本地结帐是否确实现在是 your_branch，您可以更新：
svn info | grep URL
svn up
5 - 如有必要，提交新的更改。
更新分支
您已经在 your_branch 上进行了一段时间的开发，其他人也在主干上进行了开发，现在您必须将他们的更改添加到 your_branch。
1 - 首先，更新您的分支结帐并提交任何未完成的更改。
2 - 搜索 Subversion 日志以查看您上次合并更改的修订版本号（或者，如果您从未合并过，则创建原始分支的时间）。这对于成功合并至关重要：
svn log --limit 500 | grep -B 3 your_branch
3 - 另请注意当前的头部修订版本：
svn info svn://server.com/svn/repository/trunk | grep Revision
4 - 将主干上最后合并的修订版本与主干上的头部修订版本的差异合并到 your_branch 工作副本中，将 LAST_MERGED_REVISION 替换为中记录的修订号步骤 2 和 HEAD_REVISION 以及步骤 3 中记录的修订号：
svn merge -r LAST_MERGED_REVISION:HEAD_REVISION \
svn://server.com/svn/repository/trunk .
5.a - 查找输出中的错误。所有文件都能找到吗？是否删除了不该删除的内容？也许你做错了。如果需要恢复，请运行 svn revert -R
5.b - 如果 5.a 中一切正常，检查冲突，解决任何发现的冲突：
svn status | egrep '^C|^.C'
6 - 提交合并，将 COMMAND 替换为步骤 4 中的确切命令内容：
svn ci -m "Merged changes from trunk to your_branch: COMMAND"
将分支折叠回主干
嘿，your_branch 已完成。现在它必须成为主干。
1 - 首先，遵循上一节中的每个步骤（“更新分支”），以便 your_branch 与主干上的任何最新更改保持同步。
2 - 完全删除主干：
svn del svn://server.com/svn/repository/trunk
3 - 将 your_branch 移动到旧主干位置：
svn mv svn://server.com/svn/repository/branches/your_branch \
svn://server.com/svn/repository/trunk
4 - 将工作副本重新定位回主干：
svn switch --relocate \
svn://server.com/svn/repository/branches/your_branch \
svn://server.com/svn/repository/trunk
完成！
请对此程序提供任何建议、评论或反馈。
My question is, when merging as per the procedure below, is the last step of the procedure "folding the branch back into trunk" the proper way to do this, in a best-practices scenario?
I've been using svn for many years now. In my personal projects, I always hack away happily on trunk without second-thoughts and having versioning in a single-line linear fashion has been close to perfect for a long time. Simple and efficient. All was bliss, until the day I wanted more control over 3rd party libraries.
Today, I am on a project that I feel has outgrown the hack-straight-from-trunk approach. I have multpiple 3rd party libraries, some that change weekly, and I really need more control on what goes in. I need the ability to view specific changesets between 3rd party lib version and track changes I made to specific libraries. I have seen a few times a codebase get very confusing and hard to bring back in workable state with inexperienced buildmaster, I cannot afford time-wise to go wrong here.
So I looked into vendor branching, read a few articles here and there. I have the great 'Version Control with Subversion' book, but the examples I see are sometimes contradictary in their approach, and I would like to make sense of 'branching'. I was about to follow the approach given on this post by Evan Weaver.
I laid out the procedure below, my concern is in the last section "Folding the branch into trunk". It seems buildmasters I worked with in the past usually "merged" the branches changeset onto trunk, and I don't think branches were even deleted. Is this a proper approach?
Creating the Branch
1 - Note the current head revision:
svn info svn://server.com/svn/repository/trunk | grep Revision
2 - Make a clean, remote copy of trunk into the branches folder. Name it something. We’ll call it your_branch, replacing HEAD_REVISION with the revision number you noted in step 1.:
svn cp svn://server.com/svn/repository/trunk \
svn://server.com/svn/repository/branches/your_branch \
-m "Branching from trunk to your_branch at HEAD_REVISION"
3 - switch your local checkout to point to the new branch (this will not overwrite your changes):
svn switch --relocate \
svn://server.com/svn/repository/trunk \
svn://server.com/svn/repository/branches/your_branch
4 - Check that your local checkout is definitely now your_branch, and that you can update ok:
svn info | grep URL
svn up
5 - Commit your new changes if necessary.
Updating the branch
You’ve been developing for a while on your_branch, and so have other people on trunk, and now you have to add their changes to your_branch.
1 - First, update your branch checkout and commit any outstanding changes.
2 - Search the Subversion log to see at what revision number you last merged the changes (or when the original branch was made, if you’ve never merged). This is critical for making a successful merge:
svn log --limit 500 | grep -B 3 your_branch
3 - Also note the current head revision:
svn info svn://server.com/svn/repository/trunk | grep Revision
4 - Merge the difference of the last merged revision on trunk and the head revision on trunk into the your_branch working copy, replacing LAST_MERGED_REVISION with the revision number noted in step 2 and HEAD_REVISION with the revision number noted in step 3:
svn merge -r LAST_MERGED_REVISION:HEAD_REVISION \
svn://server.com/svn/repository/trunk .
5.a - Look for errors in the output. Could all files be found? Did things get deleted that shouldn’t have been? Maybe you did it wrong. If you need to revert, run svn revert -R
5.b - If things seem ok in 5.a, check for conflicts, resolve any found conflicts:
svn status | egrep '^C|^.C'
6 - Commit the merge, replacing COMMAND with the exact command contents from step 4.:
svn ci -m "Merged changes from trunk to your_branch: COMMAND"
Folding the branch back into trunk
Hey, your_branch is done. Now it has to become trunk.
1 - First, follow every step in the previous section (“updating the branch”) so that your_branch is in sync with any recent changes on trunk.
2 - Delete trunk completely:
svn del svn://server.com/svn/repository/trunk
3 - Move your_branch onto the old trunk location:
svn mv svn://server.com/svn/repository/branches/your_branch \
svn://server.com/svn/repository/trunk
4 - Relocate your working copy back to trunk:
svn switch --relocate \
svn://server.com/svn/repository/branches/your_branch \
svn://server.com/svn/repository/trunk
Done!
Please, any advice, comments or feedback on this procedure is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您还没有这样做，我建议您阅读 此处分支+合并部分。
您引用的帖子相当旧（2007 年 8 月）并且已经过时。从 subversion 1.5（2008 年 6 月）开始，合并跟踪已经有了很大的改进（您可以创建分支并执行合并，并且 subversion 实际上会跟踪哪些修订已经从主干合并到您中）。 Subversion 1.6（2009 年 3 月）对此进行了进一步改进。
我特别不喜欢这个建议
作为管理主干的一种方式。这看起来充其量有点容易出错（如果两个功能分支想要同时合并回来会发生什么）。我倾向于分享 该帖子的最新评论。
相反，您可以在准备好时执行“重新集成”合并，以从分支合并回主干。这会将相关变更集从分支应用到主干。
If you haven't already done so, I'd suggest your read the branching + merging section here.
The post you've referenced is quite old (August 2007) and out of date. As of subversion 1.5 (June 2008), merge tracking has improved a lot (you can create branches and perform merges and subversion actually tracks which revisions have already been merged in from the trunk for you). This has been improved further in subversion 1.6 (March 2009).
I particularly dislike this suggestion
As a way of managing the trunk. This seems somewhat error prone at best (what happens if two feature branches want to merge back at the same time). I tend to share the view of the most recent comment on the post.
Instead, you can perform a 'reintegrate' merge to merge back from your branch into the trunk when you're ready to do so. This applies the relevant changesets from your branch to the trunk.
--relocate 选项是切换到另一个存储库。新分支是主干的副本，因此要进行切换。
只要这样做：
这个更新大多数时候不会做任何事情。
大多数时候我使用 TortoiseSVN 但只尝试：
尝试一下这是否有效，它应该有效。关于合并跟踪，较新的 SVN 使用 merge-info 属性，因此大多数时候它应该知道要合并什么。如果存在问题，您的方法应该效果很好。
删除分支的部分让我害怕......
尝试：
#注意你的分支应该是最新的（尽早解决大部分冲突）在分支上）
svn 开关 ^/trunk
svn merge --reintegrate ^/branches/your_branch 。
解决冲突;)
svn commit -m“重新集成your_branch”
svn delete ^/branches/your_branch
大多数时候，如果您不知道如何处理该分支，最好删除它（这并不那么容易，所以最好删除它并创建新分支）。
另请注意更改名称/重新定位在其他分支/主干中更改的文件。这将导致树冲突。如果其他分支没有变化，可以自由进行。
--relocate option is to switch to another repo. New branch is a copy of trunk so do switch.
Just do:
This update most of the time will do nothing.
Most of the time I use TortoiseSVN but try only:
Try if this will work, it should. About merge tracking, newer SVN uses merge-info property so most of the time it should know what to merge. It there are problem Your approach should work well.
Part with deleting branch scares me...
Try:
# note that your branch should be up-to date (resolve most of conflicts early on branch)
svn switch ^/trunk
svn merge --reintegrate ^/branches/your_branch .
resolve conflicts ;)
svn commit -m "reintegrated your_branch"
svn delete ^/branches/your_branch
Most of the time this is better to remove this branch if you do not know how to deal with it (it is not so easy so better is to delete it and create new).
Also Beware of changing names/relocating files that you change in other branch/trunk. This will lead you to tree conflicts. Free to do it if there are no changes in other branches.