I'm keeping track locally of a few patches to a project that uses SVN, and I also submit these patches for consideration to that other project via "svn diff" patch files that I attach to issues I open in that project's issue tracking system. I've run into a case now where I want to patch a certain file that already has another of my local patches that hasn't been accepted by that upstream team. If I use "svn diff" to generate my latest patch file, the patch file contains both the old and new patches. I'm wondering what the best way is to keep this from getting too complicated as I move forward.
Each night I run a scripted rebuild of my project (which I keep in git), and this rebuild includes compiling the latest version of the upstream svn project, after the rebuild script applies the patches I'm keeping track of locally. Currently my local patches are kept as "svn diff" patch files in a "patches" directory of my git-managed project. I'd like these local patch files to be a set of separate patch files, one patch file for each issue that I've run into, addressed locally, and then submitted to the upstream team for consideration. I'm not stuck on the idea of keeping all my patch files separate like this, but it's seemed to make sense up to this point.
How should I keep all this straight locally, and also be able to easily generate patch files suitable for submission to the upstream project that's in SVN? I'm willing to set up my own local SVN repo if that would somehow help. I'm doing all this on Debian, and I want to keep the ability to script a nightly rebuild of everything.
Thanks.
