I'd inherited a 4 month old branch which needed to be merged back into trunk at some point. As a first step, I wanted to merge the (hopefully smaller) changeset from trunk back into the branch. I tried git-svn. It didn't work for me. This has not been a pretty task.
$ pushd path/to/svn/repo
$ svn sw https://example.com/svn/project/branches/my-branch
$ svn up
$ svn merge https://example.com/svn/project/trunk --accept postpone
...
svn: One or more conflicts were produced while merging r3097:4432 into
'.' --
resolve all conflicts and rerun the merge to apply the remaining
unmerged revisions
At this point I have my working copy in a partially merged state with various file-level and tree/directory level conflicts. As an example of how a repository might get into this state, imagine this happening in the branch
$ svn mv dir1 dir2
$ mkdir dir1
...
# add files to dir1
# and commit a few times.
Meanwhile in trunk
...
# add and modify files in dir1
# commit a few times.
Since the changes hadn't been cherrypicked, you get tree conflicts. Let's take a look at those conflicts.
$ svn stat | grep 'C '
I had 46 issues listed for the merge up to this point. File level conflicts can be easily resolved using fmresolve which I've written about previously.
$ fmresolve path/to/conflicted/file
and then
$ svn resolve --accept working
or
$ svn resolve --accept theirs-full
or
$ svn resolve --accept mine-full
Tree conflicts can only be resolved using the working copy, so I needed to checkout / copy the relevant file and edit until I was happy with each one, and then mark each conflict as resolved, accepting the working copy. 21 of these needed attention at this stage.
Then you can proceed with the merge.
$ svn merge https://example.com/svn/project/trunk --accept postpone
Repeat until done.
Hopefully merging the branch back into trunk will go a little easier.
