如何使用 subclipse 合并代码更改？

发布于 2024-09-15 18:09:09 字数 191 浏览 6 评论 0原文

我第一次使用 svn 来维护 WordPress 的自定义版本。我在 eclipse 中使用 subclipse 插件。是时候将最新版本的 Wordpress 中的更改与我的自定义代码库合并了。我尝试创建一个分支并在其中添加新的 WordPress 版本，然后执行合并。但没有做出任何改变。有人可以引导我完成这样的项目设置吗？我担心我错过了一些基本的东西。谢谢。

原文

分享到QQ

分享到微博

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

发布评论

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

老娘不死你永远是小三 2024-09-22 18:09:09

假设您将从branch（包含最新版本的Wordpress）合并到trunk（您的自定义代码库）。

（确保您已将所需的所有内容提交到 branch 中。）
< p>团队 -->切换到另一个分支/标签/修订...将工作副本转移到主干（合并操作的目标），并解决任何冲突此时出现。
团队 -->合并 打开一个对话框，您将在其中执行合并操作。将“From”URL 更改为引用branch（合并操作的源，即您想要合并到工作副本中的内容）。 “From Revision”应指向 branch 中您希望合并操作“开始”的修订版本 - 通常是上次从 branch 合并到 的修订版本>trunk （或者很可能是您的情况下的头部修订版，如果您确实想合并 branch 中的最新更改）。
将“To Revision”设置为指向 branch 中的最新修订版（= 头部修订版）。
此时，您已准备好执行合并 - Dry run 命令可让您预览合并期间将发生的情况，而 Merge 将执行实际的合并。< /p>
合并操作完成后，您需要确保对工作副本执行的所有更改都正确，并解决所有冲突。
解决完冲突并检查更改后，通过一次提交操作将更改提交到trunk。为了您自己的方便，强烈建议您添加一条提交消息，在其中明确说明此提交的用途（= 将 X 到 Y 的修订从 branch 合并到 trunk 、目的是什么，等等）。

希望这有帮助。

回复收藏 0 原文

执妄 2024-09-22 18:09:09

将 WordPress 项目转换为供应商分支程序

如果您是第一次使用 svn，我想您还没有从干净的 WordPress 副本开始，从那里分支并编辑分支版本，是吗？ ;)

如果是这样，您可能会遇到问题。

背景

与“常规差异”不同，SVN 合并不会将右侧代码/文件夹与左侧代码/文件夹进行比较。
虽然 svn merge 如果没有找到历史记录，可能会退回到类似 diff 的机制，但我不建议依赖它，因为它很容易出现不必要的冲突。

SVN 合并用于重现已记录在 SVN 历史记录中的更改。这就像告诉画家“嘿，你知道在你在山上添加那棵树之前这张照片是什么样子吗？那棵树太棒了！看这里，我复制了相同的基础图片，但现在它带有日落。你能画同样的东西吗？”又是一棵树，但在这张有日落的照片上？”
画家也许能够复制这棵树，因为他知道他是如何做到的。他甚至可能在某个地方有草稿。

上图，就是wordpress。画家，它的svn由你指挥。这棵树就是你的修改。现在以日落为主题的图片是较新的 WordPress 版本。

您最有可能所做的是将 wordpress vanilla 复制到您的 svn 中，修改它，然后使用它。

继续使用图片示例，历史记录将包含“复制整张图片、添加树、添加叶子”等命令。

现在你带来了一个新版本的wordpress，可以说是一张新图片，并将其放在旧的修改版本旁边。问题是，人类和聪明人都知道它几乎是相同的图片，即使新版本不同，您也只需复制树即可，SVN 不具备这种知识。对于 SVN，您的 WordPress 1.7 文件夹（已修改）与 WordPress 1.8 完全不同。它们不共享历史记录，因为 SVN 日志中没有任何内容表明这一点。 SVN 是一个官僚势利小人，不是吗？ ;)

现在，人们为了让 svn 保持 wordpress 1.7、修改后的 1.7 和新的 1.8 之间的历史联系，所做的就是在他们的工作开始时使用分支。

因此，您可以从“vanilla-wordpress”文件夹中的一个干净的 1.7 wordpress 开始，将其存储在 svn 中并将其分支到“my-modified-wp”。在那里你可以不断地修改，直到你想从上游更新 WordPress。然后，人们下载最新的 WordPress 副本，覆盖他们的普通 WordPress 并合并生成的变更集。

在图片示例中，命令如下：

"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"

您可以清晰地再现日落，因为您知道应用日落之前图片的外观。

但你的问题是，你并没有以这种方式开始，而是立即在下载的 WordPress 上进行编辑。因此，您较新的 WordPress 副本无法轻松地与您的修改版本关联。

建立历史关系的一种方法

download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.

现在来了技巧部分
向后滚动“old-modified-wordpress”的 svn 日志。你没有分支的那个。在初次导入旧 WordPress 后，您必须找到第一个修订版。一旦你找到了那个版本，你就获取它的编号并在这两个命令的第二个中使用它：

change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.

你告诉 svn 以下内容：“在我的旧分支中获取版本 4 和 NOW 之间的所有更改，并重现它们在我的新分支上。”

如果一切顺利，您应该有两个相同的分支。旧修改版和新修改版略有不同，新修改版与您的“/vendor/wordpress/current”分支有着悠久的历史。

此祖先允许您连续执行以下操作：

Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit

我在链接中用较少的故事讲述来描述此过程。但在它发挥作用之前，你必须建立分支之间的祖先关系。

Subversion svn:externals 文件覆盖？

我知道有很多东西需要阅读：）。如果您打算进行一些绘图，请考虑“更改命令”而不是状态，这样就可以了。

Converting wordpress project to vendor branch procedure

If you are using svn for the first time I suppose you have not started with a clean wordpress copy, branched from there and edited the branched version, have you? ;)

If that is so you might have a problem at your hands.

Background

Unlike "regular diffs" SVN merge does not compare right-side code/folders with left-side code/folders.
While svn merge might fall back to a diff-like mechanism if it does not find a history, I would not recommend relying on that as it can be quite prone to unneccessary conflicts.

SVN Merge is used to reproduce changes that have been recorded in the SVN history. It is like telling a painter "Hey you know how this picture looked before you added that tree on the hill? That Tree was great! Look here i've copied the same base picture but now it's with a sunset. Can you paint the same tree again but on this picture with the sunset?"
The painter might be able to reproduce the tree because he knows how he had done it. He might even have a draft somewhere.

The picture, that is wordpress. The painter, its svn with you commanding it. The tree thats your modifications. The picture now sunset-themed is the newer wordpress version.

What most likely you did is copy wordpress vanilla into your svn, modify it, work with it.

To stick with the picture example, the history would contain commands like "copy whole picture, add tree, add leaves".

Now you bring a new version of wordpress, a new picture so to say and put it besides your older modified version. The Problem is, you human and smart know its quite much the same picture and even though the newer verison is different you just have to copy the tree, SVN does not have that knowledge. For SVN your wordpress 1.7 folder (modified) is completly distinct from wordpress 1.8. They share no history because nothing in SVNs log indicate it. SVN is a bureaucratic snob isn't it? ;)

Now what people do to allow svn to maintain that historic connection between wordpress 1.7, your modified 1.7 and the new 1.8 is they use branching right at the beginning of their works.

So you would start off with a clean 1.7 wordpress in a "vanilla-wordpress" folder, store it in svn and branch it to, say, "my-modified-wp". There you hack away until you feel like updating wordpress from upstream. People then download the latest wordpress copy overwrite their vanilla wordpress and merge the resulting changeset.

In the picture example commands would be these:

"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"

You can cleanly reproduce the sunset because you know how the picture looked before the sunset was applied.

Your problem though is that you did not start that way off but edited on your downloaded wordpress right away. So your newer copy of wordpress can not be easily associated with your modified version.

One way to establish history relations

download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.

Now comes the trick part
Scroll back the svn log of your "old-modified-wordpress". The one that you did not branch. You have to find the first revision AFTER your initial import of the old wordpress. Once you found that revision you take its number and use it in the second of these two commands:

change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.

You are telling svn the following: "Take all changes in my old branch between revision 4 and NOW and reproduce them on my new branch."

If all works out you should have two identical branches. the old-modified and the new-modified with the slight difference that the new-modified has a solid history with your "/vendor/wordpress/current" branch.

This ancestry allows you to contunously do the following:

Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit

This procedure I describe with less storystelling at the link allready. But before it can work you have to establish the ancestry relation between the branches.

Subversion svn:externals file override?

I know it has been alot to read :). If you plan do soem drawing, think of "change commands" not states and you'll be fine.

回复收藏 0 原文

~没有更多了~