Have you talked to the project lead(s)? Do your changes make general sense, or is it very specific to your needs? If you can't work what you need into the main project, you can certainly branch their tree, just keep merging as you go.
You can look into the capabilities of something like GIT too (which can interact with the original svn just fine) for accepting partial merge/patch. The further you diverge, the more this will be an issue. You can do it with svn and a good editor of course, but your life may be made easier with more flexible tools.
This is a variant of Visko's recommendation, with the opposite assumption that you'll spend most of the time making your own changes, and only occasionally integrating a fresh version of the original source-project. (Using Subversion vocabulary below.)
Create project, commit original-source as trunk. Tag.
As you make your local changes, uses branches as necessary, merge back into trunk for release, etc.
When there's a new version of the original-source-project you want to integrate:
make a branch for it;
load (hack) source over the branch files;
merge trunk into branch (because it could take some time, and you don't want to break your trunk);
then merge branch back into trunk. Tag.
That's the process I just designed in my head for my own use. Would love feedback on it.
Import a subversion-dump of the original project and start your fork with an own repository as a branch- As the original project improves, you can import the changes and then call 'svn merge' to incorporate these improvements. As long as you and the original project don't do some restructuring (renaming source-files, moving between directories etc.) the merges should work mostly.
Best practice is to first try to merge your changes into the project.
If that's not an option you just
import their current HEAD,
make your modifications in a branch
update your tree from theirs
merge and rebranch
Steps 3 and 4 are relevant to keep your fork current. It is a lot of work, depending on the project's activity and the importance to stay current. If very important I'd update and merge at least once a week.
You might prefer to import their svn tree into git to make merging easy, which is what you'll be doing the most
The best thing to do is not to fork it. Why not figure out how to improve it so it will do what you want it to do and not lose any existing functionality. If code size is an issue, maybe you can spend some of the time you would spend forking it on improving the existing projects efficiency.
I think getting your things upstream is the safest way as you get all bug fixes for free and changes made upstream will not break your things as other contributors have to respect your "features" as well b/c they are first class citizens in the project. If that is not a viable option, I'd say git with it's subversion bridge is the way to go as it has already a lot of functionality that is useful for forking, which is the natural way to do things in git anyway as everything is kind of a fork of a different repo.
发布评论
评论（6）
您与项目负责人交谈过吗？ 您的更改是否具有普遍意义，还是非常适合您的需求？ 如果您无法将所需的内容添加到主项目中，您当然可以对他们的树进行分支，只需不断合并即可。
您也可以研究像 GIT 这样的东西的功能（它可以与原始 svn 很好地交互）来接受部分合并/补丁。 分歧越大，这个问题就越严重。 当然，您可以使用 svn 和一个好的编辑器来完成，但是使用更灵活的工具可能会让您的生活变得更轻松。
Have you talked to the project lead(s)? Do your changes make general sense, or is it very specific to your needs? If you can't work what you need into the main project, you can certainly branch their tree, just keep merging as you go.
You can look into the capabilities of something like GIT too (which can interact with the original svn just fine) for accepting partial merge/patch. The further you diverge, the more this will be an issue. You can do it with svn and a good editor of course, but your life may be made easier with more flexible tools.
这是 Visko 建议的一个变体，相反的假设是您将花费大部分时间进行自己的更改，并且只是偶尔集成原始源项目的新版本。 （使用下面的 Subversion 词汇。）
创建项目，将原始源代码提交为主干。 标签。
当您进行本地更改时，根据需要使用分支、合并
返回到主干以进行发布等。
当您想要集成原始源项目的新版本时：
这就是我在脑海中设计的供我自己使用的流程。 希望得到反馈。
This is a variant of Visko's recommendation, with the opposite assumption that you'll spend most of the time making your own changes, and only occasionally integrating a fresh version of the original source-project. (Using Subversion vocabulary below.)
Create project, commit original-source as trunk. Tag.
As you make your local changes, uses branches as necessary, merge
back into trunk for release, etc.
When there's a new version of the original-source-project you want to integrate:
That's the process I just designed in my head for my own use. Would love feedback on it.
导入原始项目的 subversion-dump 并使用自己的存储库作为分支启动您的 fork - 随着原始项目的改进，您可以导入更改，然后调用“svn merge”来合并这些改进。 只要您和原始项目不进行一些重组（重命名源文件、在目录之间移动等），合并应该大部分有效。
Import a subversion-dump of the original project and start your fork with an own repository as a branch- As the original project improves, you can import the changes and then call 'svn merge' to incorporate these improvements. As long as you and the original project don't do some restructuring (renaming source-files, moving between directories etc.) the merges should work mostly.
最佳实践是首先尝试将更改合并到项目中。
如果这不是一个选项，您只需
第 3 步和第 4 步与保持您的分叉最新相关。 这是一项艰巨的工作，具体取决于项目的活动以及保持最新状态的重要性。 如果非常重要，我会每周至少更新和合并一次。
您可能更喜欢将他们的 svn 树导入 git 以使合并变得容易，这是您最常做的事情
Best practice is to first try to merge your changes into the project.
If that's not an option you just
Steps 3 and 4 are relevant to keep your fork current. It is a lot of work, depending on the project's activity and the importance to stay current. If very important I'd update and merge at least once a week.
You might prefer to import their svn tree into git to make merging easy, which is what you'll be doing the most
最好的办法就是不要分叉它。 为什么不弄清楚如何改进它，让它做你想做的事，而不丢失任何现有的功能。 如果代码大小是一个问题，也许您可以花一些时间来提高现有项目的效率。
The best thing to do is not to fork it. Why not figure out how to improve it so it will do what you want it to do and not lose any existing functionality. If code size is an issue, maybe you can spend some of the time you would spend forking it on improving the existing projects efficiency.
我认为将你的东西放到上游是最安全的方法，因为你可以免费获得所有错误修复，并且上游所做的更改不会破坏你的东西，因为其他贡献者也必须尊重你的“功能”，因为他们是项目中的一等公民。 如果这不是一个可行的选择，我会说 git 及其颠覆桥是可行的方法它已经有很多对 fork 有用的功能，无论如何，这是在 git 中做事情的自然方式，因为一切都是不同存储库的 fork。
I think getting your things upstream is the safest way as you get all bug fixes for free and changes made upstream will not break your things as other contributors have to respect your "features" as well b/c they are first class citizens in the project. If that is not a viable option, I'd say git with it's subversion bridge is the way to go as it has already a lot of functionality that is useful for forking, which is the natural way to do things in git anyway as everything is kind of a fork of a different repo.