Is there a way to "plan" my code for open source, since an open source project will improve my changes, will it be localized?

Question

I don’t know how to ask this. I want to use a mature and actively updated open source project, using it as the basis for customization and training. I would like to be able to add code to my local source, but to be able to update the main source as it improves while keeping my additions.

The goal is to keep the foundation up to date and adding my code to the updated build (instead of writing to the changes as I expected, it will happen if I just edit the source as it is).

Is there a way to "copy" my code to the updated project code, so when the source is updated using svn, my changes will remain independent of the foundation? I'm sure there is an easy way to do this, but I'm new to programming / svn / version control and don't know what and where to look.

Answer 1

What you are looking for is called SVN Vendor Industries .

Basically, you save a separate branch in your repository only for the basic versions of the project, and then merge the changes between the 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' 

Now we have:

• The "current" branch that has the latest version of the main code that you use.
• The "1.0.0" tag of the main code (you should not introduce any new changes to this tag)
• Your trunk, which now has 1.0.0 core code.

Now, let's say you worked on the project for several months and made a bunch of updates for the project in your trunk. The kernel version 1.1.0 has been released, and you want to use some new functions without losing your work.

You can use your provider's branches for this.

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

* extract version 1.1.0 on top of a 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:

• Tag for version 1.0.0 of the project
• Tag for version 1.1.0 of the project
• A string with a modified version of the project that we want to update.

So what do we need to do? 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 say that SVN does in the line above is essentially: "Find the differences between project version 1.0.0 and project 1.1.0, and then combine these differences into my modified version of the project."

For most files, merging will be smooth and painless. For others that you and the community have changed at the same time, SVN will complain about conflicts. If you have not made huge changes really , these conflicts should not be difficult to merge. I recommend choosing " p " for "Delay conflict resolution" and resolve them using TortoiseSVN. It is much, much easier to do so.

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

... and you're done!

Some more reference materials on the topic:

• Upgrading Drupal Using SVN Provider Branches

Answer 2

You can install version control system locally.

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

Then make your changes on top of this.

When the base project is updated, get a new copy, and then merge the changes into your modified code. Exactly how you do this will depend on your version control system.

However, if the project source control supports branching (what it needs), you can create a branch on your server and merge between them, which can be much simpler.

Answer 3

The closest I can think of is to start with the open source code in the trunk of your SVN repository, and then fork it and make changes to the branch. When the OSS code is updated, you update the trunk, and then merge with your branch from the trunk. At this point, you will resolve any conflicts that could occur between what they changed, and you changed, essentially "fixing" your changes in your code.

Answer 4

While I personally did this through Mercury, you could look into the quilt tool.

Also check out this review .

Answer 5

The way to do this in SVN is to check the working copy of the code, make changes to the working copy, and then, when you svn update , it will take the latest version of the code from the repository while maintaining local changes. He will notify you if there is any conflict.

I think the answers regarding branching and merging and distributed version control systems (e.g. Mercurial, Git) are more complicated than you need.

Answer 6

It looks like your usecase exactly matches the Mercurial Queue mechanism. I would say that even for a full-fledged newcomer to the mercury, it is simply easy to configure and maintain.

Answer 7

Use another modern version control system. A good candidate would be git, which is used to develop the Linux kernel worldwide. branching and merging come much more naturally than with svn.