On Mon, Oct 8, 2018 at 3:04 AM Mark Thomas <ma...@apache.org> wrote: > On 06/10/18 23:08, Igal Sapir wrote: > > I am rather new to SVN, and actually use it mostly via GIT, i.e. `git svn > > rebase` and `git svn dcommit`. > > > > What is the best way to backport specific patches from trunk to 8.5, 7.0, > > etc.? Patch utility? SVN Merge? GIT cherry-pick (though the git > mirrors > > have a separate repos which adds some complexity I think) > > > > I'd appreciate any tips that will point me in the right direction, or if > > anyone can share their workflow. > > I use svn for backports. I use the following scripts. The first to merge > from trunk to 8.5.x, the second to merge from 8.5.x to 7.0.x. I `cd` > into the root of the repo for the version I want to merge to and then > call the script with the revision of the commit I want to back-port. > > HTH, > > Mark > > mark@study04:~/bin$ cat tc-merge.sh > #!/bin/sh > svn up > svn merge -c $1 https://svn.apache.org/repos/asf/tomcat/trunk > > mark@study04:~/bin$ cat tc85-merge.sh > #!/bin/sh > svn up > svn merge -c $1 https://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk > > It helps, thanks, but I don't know if the target file has been changed or if I did something wrong, I'm getting a conflict (in git I can see the differences and choose resolution, but here I don't know which one to pick). Or is it because I waited too long and didn't do this immediately after committing the original patch to trunk?
Here's the output from the script: tc8.5.x]$ ~/bin/svn-merge-tc-trunk-to-85.sh 1842849 Updating '.': At revision 1843219. --- Merging r1842849 into '.': C test C java --- Recording mergeinfo for merge of r1842849 into '.': U . Summary of conflicts: Tree conflicts: 2 Searching tree conflict details for 'java' in repository: Checking r1842849... done Tree conflict on 'java': Changes destined for a directory arrived during merge of '^/tomcat/trunk/java:1842849'. No such file or directory was found in the merge target working copy. The item may have been deleted or moved away in the repository's history. Subversion is not smart enough to resolve this tree conflict automatically! Apparently neither am I :s
