SVN - 管理修订的部分合并

发布于 2024-08-17 23:53:30 字数 950 浏览 4 评论 0原文

所以我在 Subverion 中遇到了一个让我非常悲伤的问题。我正在一个分支工作,该分支应该保持活跃状态​​,直到我的功能集开发完成后再重新集成。不幸的是,我已经完成的一些事情现在被企业认为是“关键任务”,他们希望我从分支中挑选出该功能并将其推入主干,以便质量检查可以拾取它。

我遇到的问题是,我在一个单独的目录中开发了该功能,该目录是我在完全处理其他事情时创建的。因此,为了合并我的功能所需的剩余代码,我首先需要提取之前创建的目录。

以下是我需要撤回的修订:

Rev 20
 一个./project_foo
  ./project_foo/not_required_file.txt

修订版 24
A ./project_foo/required_file.txt

因此,要将其放入主干中,我必须执行以下操作:

svn merge -r20:21 ->这让我获得了目录以及 not_required_file.txt
svn 恢复project_foo/not_required_file.txt ->删除我不想要的文件
svn merge -r24:25 - >这让我得到了我需要的文件

它有效并将内容放入了我想要的主干中,但是当我完成开发并运行 svn merge --reintegrate 时,我(显然)没有从修订版中获取 not_required_file.txt 20,因此遇到了树冲突(来自我后来所做的进一步更改)。

因此,我正在寻找一些关于在这些情况下该怎么做的指导。

  • 有没有办法只合并我想要的特定修订中的特定更改?
  • 当我重新集成整个分支时,有什么方法可以抓住我故意错过的更改吗?
  • 我可以在主干中创建所需的目录结构,然后仅合并文件更改吗?
  • 我可以创建另一个分支,将所需的更改移到那里,重新集成该分支,然后从主干拉到我的原始分支吗?

谢谢。

So I have an issue that is causing me a lot of grief in Subverion. I am working in a branch that is supposed to remain active until my feature set is development complete before re-integrating. Unfortunately, something I have completed has now been deemed by the business to be 'mission critical' and they want me to cherry pick that functionality out of the branch and push it into the trunk so it can get picked up by QA.

The problem I have is that I developed the functionality in a separate directory which I created while working on something else entirely. So in order to merge the remaining code that my functionality requires, I first need to pull in the directory creation that I did previously.

Here are the revisions that I need to yank:

Rev 20
  A ./project_foo
  A ./project_foo/not_required_file.txt

Rev 24
 A ./project_foo/required_file.txt

So to get this into the trunk I had to do the following:

svn merge -r20:21 -> this gets me the directory as well as the not_required_file.txt
svn revert project_foo/not_required_file.txt -> get rid of the file I don't want
svn merge -r24:25 -> this gets me the file I require

Which worked and got the stuff into the trunk that I wanted BUT when I was dev complete and ran svn merge --reintegrate, I (obviously) did not get the not_required_file.txt back from Revision 20 and thus ran into tree conflicts on it (from further changes I made later).

So I am looking for some guidance on what to do in these situations.

  • Is there a way of merging in only the specific changes I want from a specific revision?
  • Is there any way of grabbing the changes I deliberately missed when I re-integrate the entire branch?
  • Could I create the directory structure I need in the trunk and then merge over only the file changes?
  • Can I create another branch, move the required changes over there, reintegrate that branch and then pull from the trunk to my original branch?

Thanks.

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

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

发布评论

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

评论(4

梦幻之岛 2024-08-24 23:53:30

有没有办法只合并
我想要的具体改变
具体修改吗?

如果您不需要完整的修订,我会通过创建补丁文件并将其应用到其他分支并提交来手动复制您想要的内容。这样,subversion 不会稍后跳过该修订(当您重新集成分支时),而是尝试合并它,您只需处理手动复制内容的普通冲突,但它也会合并您最初想要跳过的部分。

在创建/删除/添加文件的情​​况下,它会在重新集成时创建它并避免树冲突,因为您想要的“部分修订”从未正式合并。

在没有创建/删除/移动文件的情况下,您可以避免忘记的可能性
您之前合并时排除了部分修订版本。

遵循上述步骤可以防止您发生下一个:

有什么办法可以获取
当我故意错过的变化
重新整合整个分支?

如果您不合并部分修订,则 subversion 不会记录任何故意排除的内容,您应该只处理已复制的部分的普通冲突。

在你的情况下,你也许可以告诉 subversion 再次合并那个单独的修订版,执行与你之前所做的相反的操作(解决冲突或恢复你最初想要的部分,同时保留你最初遗漏的部分),但我'一旦合并已经被记录,我不确定这是如何工作的。

或者,如果您使用 TortoiseSVN,您应该能够在日志中选择修订(在您的功能分支上),右键单击您关心的作为该修订的一部分进行修改的文件,然后“将更改显示为差异” ,保存它,然后手动将其应用回主干(或任何一个分支是我们重新集成分支的目标)。

我可以创建目录结构吗
我需要放在后备箱然后合并
仅更改文件?

尝试一下看看。最坏的情况是,您签出另一个工作区或手动修复文件的内容(如果它跳过它)

我可以创建另一个分支,移动
那里需要改变,
重新集成该分支,然后拉取
从主干到我原来的分支?

现在你只是让我头疼:)手动修复它听起来对我来说工作量更少。我会修复您在主干上排除的部分,然后重试重新集成分支。

希望其中的某些部分有所帮助。

Is there a way of merging in only the
specific changes I want from a
specific revision?

If you don't want a full revision, I would copy over what you want manually by creating a patch file and applying it to the other branch and committing. That way, instead of subversion skipping that revision later (when you reintegrate the branch), it tries to merge it and you just deal with an ordinary conflict on what you manually copied, but it also merges over the part you originally wanted to skip.

In the case of a file create/delete/add, it would create it at the time of reintegration and avoid your tree conflict, since that 'partial revision' you want wasn't ever officially merged.

In the case where no file was created/deleted/moved, you avoid the potential of forgetting
that you excluded part of your revision when you merged it previously.

Following the above prevents your next one:

Is there any way of grabbing the
changes I deliberately missed when I
re-integrate the entire branch?

If you don't merge a partial revision, there won't be anything deliberately excluded recorded by subversion and you should just have an ordinary conflict to deal with on the portion already copied over.

In your case you may be able to tell subversion to merge that individual revision again, doing the reverse of what you previously did (resolving conflict on or reverting the part you originally wanted, while keeping the part you originally left out), but I'm not sure how this works once the merge has already been recorded.

Alternatively, if you use TortoiseSVN you should be able to select the revision in the log (on your feature branch), right click the file(s) you care about that were modified as part of that revision, and "show changes as diff", save that, and apply it manually back to trunk (or whichever branch is the target of our reintegrate branch).

Could I create the directory structure
I need in the trunk and then merge
over only the file changes?

Try it out and see. At worst, you checkout another workspace or manually fix the contents of the file (in the event that it skips it)

Can I create another branch, move the
required changes over there,
reintegrate that branch and then pull
from the trunk to my original branch?

Now you're just making my head hurt :) Fixing it manually sounds like less work to me. I would fix the part you excluded on trunk and then retry reintegrating the branch.

Hopefully some part of this is helpful.

亽野灬性zι浪 2024-08-24 23:53:30

只需递归地将“svn copy”丢失的文件夹从分支复制到主干即可。

just "svn copy" missing folders from the branch to trunk recursively.

我的黑色迷你裙 2024-08-24 23:53:30

对于您当前的问题,您可能会考虑 SVK,它比 SVN 具有更好的合并支持(或者上次我大量使用 SVN 以至于必须进行合并): com/view/HomePage" rel="nofollow noreferrer">http://svk.bestpractical.com/view/HomePage

不过,我注意到您提到了多个技术能力水平不同的团队的问题,所以SVK 并不是真正的最佳解决方案。实际上我更喜欢 git-svn 而不是 SVK,因为它提供了类似的好处(甚至比 SVN 或 SVK 更好的合并)。

根据您的技能水平范围的低端,SVK 可能与 SVN 足够接近,它可以做到这一点,但它确实添加了一些额外的步骤来推出更改,而且我不知道它在 Windows 下的支持情况如何(或者如果 Windows 支持),或者您的环境是否存在问题。

For your current issues, you might look into SVK, which has better merging support than SVN (or did the last time I was using SVN heavily enough to have to do merges): http://svk.bestpractical.com/view/HomePage

I notice that you mentioned the problem of multiple teams with varying levels of technical ability, though, so SVK isn't really the best solution. Actually I prefer git-svn over SVK, as it provides similar benefits (even better merging than SVN or SVK).

Depending on the low end of your range of skill levels, SVK might be close enough to SVN that it could do the trick, but it does add some extra steps to pushing out changes, and I don't know how well it's supported under Windows (or if it is supported under Windows), or if that's a problem in your environment.

何以心动 2024-08-24 23:53:30

好问题。 :-)

看起来你的分支有点混乱。您有解决问题的好主意。如果有效的话?尝试一下,有时你永远不会知道。

我认为你不需要合并 rev。在您的示例中,21 在 24 之前。无论如何,丢失的目录将会被创建。

如果您无法帮助自己进行分支/合并,请尝试手动移动文件(Tortoise 可以帮助您完成此操作)。

一般来说,避免部分合并修订。更频繁地做出承诺,这样您就可以以更干净的方式进行挑选。

Nice question. :-)

Looks like your branches are a little messed up. You have good ideas how to solve it. If it works? Try it out, sometimes you never know.

I think you don't need to merge rev. 21 before 24 in your example. The missing directory will be created, anyway.

If you can't help yourself with branching/merging, try to do the moving of files manually (Tortoise helps you with this).

In general, avoid partially merging revisions. Commit more often so you can do the cherry picking in a cleaner way.

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