Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
I need to customize an open-source project. The changes are for a specific organization and will not be useful to the public project. The code changes include disabling features not needed by the organization (affecting 5% of the code), customizing other features for the organization (affecting 20% of the code), and adding new custom features (adding about 10% new code).
I could start with the current version and customize from there. However, the original project continues to make advances and introduce new features, and I would like to be able to incorporate these improvements as they come along.
What's the best way to manage this? Right now, I can only get release versions as they become available, but I should soon have read-only access to the original project's Subversion repository. I'm new to using Subversion repositories, but have them available to use for my code as well.
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.
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.
