Correct workflow for managing a private Subversion fork:

Question

There is an open source project I would like to fork. It has a public SVN repository from which I would like to check out the source, clone it into my private repository, and begin making changes. If possible I would like to be able to merge changes from the upstream repository in the future. So far I've been able to do it like so:

1. Create a folder for this project in my own repository.
2. Check out this empty folder.
3. Check out the original project into another location.
4. Delete all .svn subdirectories in this new location.
5. Copy the files into the working copy of my private repository, commit once, then begin making changes.

This works but it seems ugly and I'm not at all convinced that merge will work correctly. Is there a better way?

EDIT: To preclude replies of "just submit a patch", suffice it to say this is for a feature I need in my application but because it deliberately breaks compatibility with the existing functionality, it will not be accepted upstream.

Answer 1

I'm going to recommend that you look at Git.

Yes, the project is using Subversion, but Git has a handy little trick of pulling a revision out of Subversion, allowing you to use Git for your own personal versioning, and then committing your changes back into Subversion.

That would allow you to remain in sync with Subversion, and still take full advantage of a revision control system.

Take a look at git svn.

If you don't want to learn Git (you might as well since most open source projects are moving to it), you can take a look at svk.