Maintain code changes to SVN repository separately, outside the repository

Question

I have a question about the best way to maintain some code.

There is a project hosted on an SVN repository online. The project is actively under development so the trunk keeps changing. I also do not have write access to this repo.

I have made some changes to this project that required changes to many modules across the project. My changes are pretty "niche" and it doesn't make sense to check them in to the trunk. Also, my changes are going to keep evolving.

The files that I've changed don't get modified much in the trunk, so even if the trunk keeps changing my changes are most likely going to remain valid if they are applied to the trunk.

Is there any way I can maintain my changes separately without mirroring the entire repository? So far, I've been maintaining a mirror of the repo that I keep merging, and this is quite time consuming. I've not had the time so my changes have gone out of sync with the latest.

Essentially, it would be great if someone who wanted to use my changes had to do something like:

1. Check out the trunk (or a specific tag) from the SVN repo
2. Check out my latest changes (or a specific tag) alone from somewhere
3. Merge the two using some script (which I can develop)

So now they have the latest trunk from the repo, and the latest of my changes, automatically merged and ready to be used.

I'm open to using any system to maintaining the changes that I've made. Doesn't have to be SVN or anything specific.

Answer 1

You could use git-svn to clone the subversion repository and then keep up your git-svn clone. If you did that, someone who wants your version/branch of the code would not need a 3-step process as you describe; rather they would just 'git clone' your repo (or a tag you specified, etc).

You could also maintain multiple branches of the svn repository's trunk, or track multiple svn branches separately, etc.

Answer 2

If you can get write access, then the best thing would be to request a branch. Then you could commit your changes to a branch and use merge to keep it updated with trunk. If not, then I would just treat this like the classic "vendor branch" scenario.

https://www.google.com/search?q=svn+vendor+branch

Basically, just create your own SVN repository locally and use script to maintain a copy of pristine trunk in your repository. Create a branch in your repository and commit your changes there. Then just periodically use script to synch trunk in your repos with trunk in master and then merge changes from that trunk to your branch.

I would guess you could also use git-svn to maintain a git mirror of trunk and then just use git branches to store your changes and keep them in synch.

Answer 3

Sounds like maybe a branch would be the best way to go. It would be available to all users, and would allow you to commit to help keep your changes manageable and in version control. People could work with you on your branch, and you could always merge changes from the trunk to your branch, and vice versa.