有没有办法“打补丁”?我的代码到开源代码中,因此随着开源项目的改进,我的更改将在本地进行?

发布于 2024-08-17 14:48:02 字数 288 浏览 5 评论 0原文

不知道如何问这个。我想建立一个成熟且积极更新的开源项目,并将其作为调整和学习的基础。我希望能够将代码添加到我的本地源中,但能够随着核心源的改进而更新核心源,同时保留我的附加组件。

目标是使基础始终保持最新,并将我的代码添加到更新的版本中(而不是被更改覆盖,正如我想象的那样,如果我按原样编辑源代码就会发生这种情况)。

有没有办法将我的代码“修补”到更新的项目代码上,这样当使用 svn 更新核心源代码时,我的更改将保持独立于基础?我确信有一个简单的方法可以做到这一点,但我是编程/svn/版本控制的新手,不知道该看什么或在哪里看。

Not sure how to ask this. I want to build upon a mature and actively updated open source project, using it as a foundation to tweak and learn from. I'd like to be able to add code to my local source, but be able to update the core source as it improves while retaining my add ons.

The goal is to keep the foundation always up to date, and adding my code to the updated build (instead of being overwritten with changes, as I'd imagine would happen if I just edited the source as is).

Is there a way to 'patch' my code onto the updated project code, so when the core source is updated with svn my changes would remain independent of the foundation? I'm sure there's a simple way to do it but I'm new to programming/svn/version control and haven't a clue what or where to look.

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

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

发布评论

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

评论(7

夜访吸血鬼 2024-08-24 14:48:02

您要查找的内容称为 SVN 供应商分支

基本上,您在存储库中仅为项目的基线版本保留一个单独的分支,然后将项目版本之间的更改合并到主干中。

例如:

svn import ./projectdir svn://repourl/project/branches/vendor/current/ -m 'Home for current core version of source code'
svn copy svn://repourl/project/branches/vendor/current/ svn://repourl/project/branches/vendor/1.0.0/ -m '1.0.0 tag of core source code'
svn copy svn://repourl/project/branches/vendor/current/ svn://repourl/project/trunk/ -m 'Initial trunk commit of 1.0.0'

我们现在拥有的是:

  • 一个“当前”分支,其中包含您正在使用的核心代码的最新版本。
  • 核心代码的“1.0.0”标签(您不应对此标签提交任何新的更改)
  • 您的主干,现在拥有 1.0.0 的核心代码。

现在,假设您已经在该项目上工作了几个月,并且对主干中的项目进行了一系列更新。核心版本 1.1.0 已发布,您希望在不丢失现有工作的情况下利用一些新功能。

您可以使用您的供应商分支来实现此目的。

svn co svn://repourl/project/branches/vendor/current/ ./project

* 在工作副本之上提取版本 1.1.0 *

svn status | grep -E '^?' | xargs svn add # add all new files/directories to the project
svn status | grep -E '^!' | xargs rm -rf  # remove all files/directories from the project that have been deleted
svn commit -m 'Version 1.1.0 of the core code'
svn copy svn://repourl/project/branches/vendor/current/ svn://repourl/project/branches/vendor/1.1.0 -m 'Tag for 1.1.0'
rm -rf ./project

现在,我们有什么?我们有:

  • 项目版本 1.0.0 的标签
  • 项目版本 1.1.0 的标签
  • 包含我们想要更新的项目修改版本的主干。

那么,我们需要做什么呢?一个简单的合并。

svn co svn://repourl/project/trunk ./project
svn merge svn://repourl/branches/vendor/1.0.0 svn://repourl/branches/vendor/1.1.0 ./project

在上面的行中,您告诉 SVN 要做的事情本质上是:“查找项目版本 1.0.0 和项目版本 1.1.0 之间的差异,然后将这些差异合并到我修改后的项目版本中。”

对于大多数文件来说,合并将是顺利且轻松的。对于你和社区同时修改的其他内容,SVN 会抱怨冲突。除非您进行了真正巨大的更改,否则这些冲突应该不难合并。我建议为“推迟冲突解决”选择“p”并使用 TortoiseSVN 解决它们。这样做要容易得多。

一旦冲突全部解决,就可以继续测试应用程序。如果一切按预期工作,请继续 svn commit 您的工作副本。

...你就完成了!

有关该主题的更多参考资料:

What you are looking for are called SVN Vendor Branches.

Basically, you keep a separate branch in your repository for baseline versions of the project only and then merge changes between versions of the project into your trunk.

For example:

svn import ./projectdir svn://repourl/project/branches/vendor/current/ -m 'Home for current core version of source code'
svn copy svn://repourl/project/branches/vendor/current/ svn://repourl/project/branches/vendor/1.0.0/ -m '1.0.0 tag of core source code'
svn copy svn://repourl/project/branches/vendor/current/ svn://repourl/project/trunk/ -m 'Initial trunk commit of 1.0.0'

What we have now are:

  • A "current" branch that has the most up to date version of the core code you are using.
  • A "1.0.0" tag of the core code (you should not commit any new changes to this tag)
  • Your trunk, which now has 1.0.0 of the core code.

Now, let's say you've been working on the project for a few months and have made a bunch of updates to the project in your trunk. Version 1.1.0 of the core comes out, and you want to take advantage of some new features without losing your existing work.

You can use your vendor branches for this.

svn co svn://repourl/project/branches/vendor/current/ ./project

* extract version 1.1.0 on top of the working copy *

svn status | grep -E '^?' | xargs svn add # add all new files/directories to the project
svn status | grep -E '^!' | xargs rm -rf  # remove all files/directories from the project that have been deleted
svn commit -m 'Version 1.1.0 of the core code'
svn copy svn://repourl/project/branches/vendor/current/ svn://repourl/project/branches/vendor/1.1.0 -m 'Tag for 1.1.0'
rm -rf ./project

Now, what do we have? We have:

  • A tag for version 1.0.0 of the project
  • A tag for version 1.1.0 of the project
  • A trunk with a modified version of the project that we want to bring up to date.

So, what do we need to do? A simple merge.

svn co svn://repourl/project/trunk ./project
svn merge svn://repourl/branches/vendor/1.0.0 svn://repourl/branches/vendor/1.1.0 ./project

What you are telling SVN to do in the line above is essentially: "Find the differences between version 1.0.0 of the project and 1.1.0 of the project, then merge those differences into my modified version of the project."

For most files, the merge will be smooth and painless. For others that both you and the community have modified at the same time, SVN will complain about conflicts. Unless you've made really huge changes, these conflicts should not be difficult to merge. I recommend selecting "p" for "Postpone conflict resolution" and resolving them using TortoiseSVN. It's much, much easier to do that way.

Once your conflicts are all resolved, go ahead and test the application. If everything is working as expected, go ahead and svn commit your working copy.

... and you're done!

Some more reference material on the subject:

横笛休吹塞上声 2024-08-24 14:48:02

我能想到的最接近的事情是从 SVN 存储库主干中的开源代码开始,然后对其进行分支并在分支中进行更改。当 OSS 代码更新时,您将用该代码更新主干,然后从主干合并到您的分支。那时,您将解决他们更改的内容和您更改的内容之间可能发生的任何冲突,本质上是将他们的更改“修补”到您的代码中。

The closest thing I can think of would be to start with the open source code in the trunk of your SVN repository, then branch it and make your changes in the branch. When the OSS code is updated, you would update the trunk with that then do a merge up to your branch from the trunk. At that point you would resolve any conflicts that might have occurred between what they changed and you changed, essentially "patching in" their changes to your code.

寒尘 2024-08-24 14:48:02

您可以在本地安装源代码控制系统。

使用项目服务器中的源副本填充它。

然后在此基础上进行更改。

当参考项目更新时,获取新副本,然后将编辑内容合并到修改后的代码中。具体如何执行此操作取决于您选择的源代码控制系统。

但是,如果项目的源代码管理支持分支(它应该),您可以在其服务器上创建一个分支并在它们之间进行合并,这可能会容易得多。

You could install a source control system locally.

Populate it with a copy of the source from the project server.

Then make your changes on top of this.

When the reference project is updated get a new copy and then merge the edits into your modified code. Exactly how you do this will depend on the source control system you choose.

However, if the project's source control supports branching (which it should) you could create a branch on their server and merge between them, which might be a lot easier.

雾里花 2024-08-24 14:48:02

虽然我个人会通过 Mercurial 来完成此操作,但您可以查看 quilt 工具。

另请查看此概述

While personally I would do this through mercurial, you might look into the quilt tool.

Also check out this overview.

等待我真够勒 2024-08-24 14:48:02

在 SVN 中执行此操作的方法是签出代码的工作副本,对工作副本进行更改,然后当您 svn update 时,它将获取最新版本的代码从存储库中删除,同时仍然保留本地更改。如果有任何冲突,它会通知您。

我认为涉及分支和合并以及分布式版本控制系统(即 Mercurial、Git)的答案比您需要的更复杂。

The way to do this in SVN is to check out a working copy of the code, make your changes to the working copy, and then when you svn update, it will grab the most recent version of the code from the repository while still keeping your local changes. It will notify you if there are any conflicts.

I think the answers that refer to branching and merging and distributed version control systems (viz. Mercurial, Git) are more complex than what you need.

何止钟意 2024-08-24 14:48:02

It looks that your usecase exactly match the Mercurial Queue mechanism.
I would say that even for a complete newbie to mercurial it's damn easy to set up and maintain.

蘸点软妹酱 2024-08-24 14:48:02

使用不同的现代版本控制系统。一个很好的候选者是 git,它在世界各地用于 Linux 内核开发。分支和合并比 svn 更加自然。

Use a different, modern version control system. A good candidate would be git which is used for Linux kernel development all over the world. branching and merging comes much more natural than with svn.

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