Subversion 分支重新整合

发布于 2024-07-04 18:30:55 字数 71 浏览 6 评论 0原文

当分支重新集成到主干时,该分支实际上已经死亡了吗?

您可以在重新集成后对分支进行修改并稍后将其合并回主干吗?

When a branch is reintegrated to the trunk, is that branch effectively dead?

Can you make modifications to the branch after the reintegration and merge those back into the trunk at a later date?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(10

迟月 2024-07-11 18:30:55

当您进行合并时,您指定目标。 如果您愿意,您可以将 TreeA 和 TreeB 的差异合并到 TreeC。 正如克里斯暗示的那样,你的问题并没有多大意义。 如果将分支合并到主干中,分支将保持不变。 如果以后不再需要该分支,可以将其删除。

When you do a merge, you specify the target. You can merge the differences of TreeA and TreeB to TreeC if you like. As Chris implies, your question doesn't really make that much sense. If you merge your branch into the trunk, the branch remains untouched. If the branch isn't needed afterwards, you could delete it.

风苍溪 2024-07-11 18:30:55

您可以继续在分支上进行开发,您需要的功能是 merge-tracking在 Subversion 1.5 中,这意味着来自分支的额外合并仅包含新的更改。

You can keep on developing on the branch, the feature you will need is merge-tracking which is in Subversion 1.5, this means that additional merges from the branch only include new changes.

林空鹿饮溪 2024-07-11 18:30:55

首先,如果您仍然使用 Subversion 1.7 或更早版本,则应该升级 Subversion 客户端和服务器。 没有理由使用非常旧的 Subversion 版本。 截至 2016 年,当前版本为 Subversion 1.9。 SVN 1.8 现在也受支持,并且仍然收到错误修复。

你问的问题已经在 Subversion 1.8 中解决了。 从 SVN 1.8 开始,--reintegrate 选项已被弃用。 现在可以自动执行重新集成合并。 请参阅与改进相关的 Subversion 1.8 发行说明条目

阅读 SVNBook 1.8 | 重新集成分支

如果您选择在将分支重新集成到
trunk,您可以继续从 trunk 执行同步合并,然后
再次重新整合分支。 如果执行此操作,则仅对
第一次重新集成后您的分支将合并到主干。

...

只有 Subversion 1.8 支持功能分支的这种重用。 早些时候
在功能分支可以被使用之前,版本需要一些特殊的处理
不止一次重新融入。 请参阅本章的早期版本
了解更多信息:
http://svnbook.red -bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

First of all, you should upgrade your Subversion client and server if you still use Subversion 1.7 or older. There is no reason to be using very old Subversion releases. As of 2016, the current version is Subversion 1.9. SVN 1.8 is also supported now and still receives bug fixes.

The problem you ask about was solved in Subversion 1.8. Beginning with SVN 1.8, --reintegrate option has been deprecated. Reintegrate merges are now performed automatically. See Subversion 1.8 Release Notes entry related to the improvement.

Read SVNBook 1.8 | Reintegrating a branch:

If you choose not to delete your branch after reintegrating it to the
trunk you may continue to perform sync merges from the trunk and then
reintegrate the branch again. If you do this, only the changes made on
your branch after the first reintegrate are merged to the trunk.

...

Only Subversion 1.8 supports this reuse of a feature branch. Earlier
versions require some special handling before a feature branch can be
reintegrated more than once. See the earlier version of this chapter
for more information:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

岁月如刀 2024-07-11 18:30:55

您可以根据需要多次从分支合并到主干,或从主干合并到分支。

You can merge from a branch to trunk, or trunk to a branch, as many times as you want.

空‖城人不在 2024-07-11 18:30:55

不,树枝还活着,但是,那一刻,它和树干一模一样。 如果您继续在分支上进行开发,则稍后可以自由地与主干重新合并。

No, the branch is still alive, but, at that moment, it is exactly the same as the trunk. If you keep developing on the branch, you are free to re-merge with the trunk later on.

始终不够 2024-07-11 18:30:55

正如每个人都已经在这里说过的那样:分支还没有死,对分支的提交可以继续正常进行。

有时你想在合并后杀死分支。 唯一可靠的解决方案是删除分支。 缺点是,如果你想看一下它,比如由于历史原因,就很难再找到它了。 因此,许多人将“重要”分支留在周围,并达成协议不更改它们。 我希望有一种方法可以将分支标记为死亡/只读,从而确保没有人可以提交它,直到另行通知。

As everyone has already said it here: the branch isn't dead and commits to the branch can continue just fine.

Sometimes though you want to kill the branch after the merge. The only reliably solution is to delete the branch. The downside is that then it's harder to find the branch again if you wanted to have a look at it, say, for historical reasons. So, many people leave the "important" branches lying around and having an agreement of not changing them. I wish there was a way to mark a branch dead/readonly, thus ensuring nobody can commit to it until further notice.

紫罗兰の梦幻 2024-07-11 18:30:55

如果有人多次更改分支(1.5 之前),有关将更改合并回来的一些建议:记住您​​在哪个版本中进行了合并! 将修订号写在某处,(这更容易)制作标签。 (当然,您可以稍后找到它,但那是 PITA。)

示例:

您有一个像这样的存储库布局:

/your_project
  /trunk
  /branches
  /tags

假设它是一个 Web 应用程序,并且您计划发布一个版本。 您将创建一个标签,并从该标签(或从主干)创建一个分支,在其中进行错误修复:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0

通过这种方式,您可以将新功能集成到主干中。 所有错误修复只会在错误修复分支内发生,并且在每次发布之前,您都会创建当前版本的标签(现在来自错误修复分支)。

假设您进行了大量的错误修复并将其发布到生产服务器,并且您在当前主干中迫切需要其中一个功能:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2

您现在可以将 1.0.0 和 1.0.2 之间的更改集成到您的主干中(假设您在你的工作副本中):

svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .

这是你应该记住的。 您已经将 1.0.0 和 1.0.2 之间的更改合并到主干上。 让我们假设当前的生产版本中有更多更改:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4

您现在已准备好从主干发布新版本,但错误修复的最后更改仍然丢失:

svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .

现在您已将所有更改合并到您的trunk,然后您就可以发布(不要忘记先测试它)。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
    /1.1.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4
    /1.1.0

Some advice on merging the changes back if someone makes changes to the branch multiple times (pre 1.5): Remember at which revision you did the merge! Either write the revision numbers down somewhere, or (which is easier) make a tag. (You can of course find it out later, but that's a PITA.)

Example:

You have a repository layout like this:

/your_project
  /trunk
  /branches
  /tags

Let's say it is a web application, and you have planned to make a release. You would create a tag, and from that (or from trunk) a branch in which you do the bugfixes:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0

Doing it this way, you can integrate the new features in the trunk. All bugfixes would happen only within the bugfix branch and before each release you make a tag of the current version (now from the bugfix branch).

Let's assume you did a fair amount of bugfixing and released those to the production server and you need one of those features desperately in the current trunk:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2

You can now just integrate the changes between 1.0.0 and 1.0.2 in your trunk (assuming you are in your working copy):

svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .

This is what you should remember. You already merged the changes between 1.0.0 and 1.0.2 upon the trunk. Let's assume there are more changes in the current production release:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4

You are now ready to release the new version from trunk, but the last changes of your bugfixes are still missing:

svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .

Now you have all changes merged on your trunk, and you can make your release (don't forget to test it first).

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
    /1.1.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4
    /1.1.0
醉南桥 2024-07-11 18:30:55

从分支重新集成到主干后,您应该执行以下两件事之一:

  • 删除您的分支。 这是最简单的,但它使查看分支的历史记录变得更加困难。

  • 告诉您的分支机构不要合并重新集成提交。 如果您重新集成到主干,并将其提交为修订版 X,则可以在分支上运行以下命令:svn merge --record-only -c X url-to-trunk。 但是,如果您在提交过程中进行了任何更改(合并本身除外),则不应执行此操作。 任何其他更改都不会返回到您的分支中。

After you reintegrate from a branch into the trunk, you should do one of two things:

  • Delete your branch. This is the easiest, but it makes it harder to see the branch's history.

  • Tell your branch not to merge the reintegrate commit. If you reintegrate to the trunk, and commit it as revision X, you can run this command on your branch: svn merge --record-only -c X url-to-trunk. However, you shouldn't do this if you made any changes as part of the commit, other than the merge itself. Any other changes will never make it back into your branch.

情仇皆在手 2024-07-11 18:30:55

实际上,您需要将 --record-only 从主干合并到由 --reintegrate 提交创建的修订版本的分支中:

$ cd trunk
$ svn merge --reintegrate ^my-branch 
$ svn commit

Committed revision 555. 
# This revision is ^^^^ important

现在您将其记录下来

$ cd my-branch
$ svn merge --record-only -c 555 ^trunk 
$ svn commit

您现在很高兴保留分支

更多信息位于第 4 章。分支和合并,高级合并

Actually, you need to do a --record-only merge from trunk into your branch of the revision that was created by the --reintegrate commit:

$ cd trunk
$ svn merge --reintegrate ^my-branch 
$ svn commit

Committed revision 555. 
# This revision is ^^^^ important

And now you record it

$ cd my-branch
$ svn merge --record-only -c 555 ^trunk 
$ svn commit

You are happy to keep the branch now

More information is in Chapter 4. Branching and Merging, Advanced Merging.

柳若烟 2024-07-11 18:30:55

你可以从技术上做到这一点,你的分支没有死亡也没有禁用,但不建议在重新集成后从分支合并到主干。

您可以在此处找到有关其原因的完整讨论:Subversion 合并重新集成

基本上,它说,可以将您的更改再次合并到主干,但是由于重新集成迫使您在重新集成操作之前从主干合并到分支,您将面临反射/循环合并,这在颠覆1.5。
根据该文章,建议重新集成后立即删除重新集成的分支,并创建一个具有相同(或不同)名称的新分支。

这是已知的 Subversion 行为,将在未来版本中解决(可能在 1.6 中)


You can do it technically, you branch is not dead nor disabled, but it is not recommended to merge from branch to trunk after reintegration.

You can find a full discussion about the reason for that, here: Subversion merge reintegrate

Basically, it says, that it is possible to merge your changes again to the trunk, but since reintegration forces you to merge from trunk to branch prior to the reintegrate operation you'll be facing Reflective/Cyclic Merge which is very problematic in Subversion 1.5.
According to the article, it is recommended to delete your reintegrated branch immediately after reintegration and create a new one with the same (or different) name instead.

This is a known Subversion behavior which will be addressed in future version (probably in 1.6)


~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文