0

I have a Ruby on Rails project that I am working on which uses SVN (1.6.17, Debian) for version control. Locally I am using Git (2.5.4, OS X) with git-svn and I have been working on a branch (called "ruby22rails42") for a major update to the project (using a new framework version) and regularly pulling in changes from SVN "trunk" to keep up to date with the project. Recently, I have created a mirror branch ("/branches/v8.5-ruby22rails42") on our online SVN server, pushed my local Git branch there and merged again with trunk for other developers to take a look.

Now I basically want "/branches/v8.5-ruby22rails42" to be the new 'trunk' and keep the old SVN trunk as a versioned branch (let's call it "/branches/v8.4-ruby19rails3"). Unfortunately, 'svn merge --reintegrate' seems to fail with "mergeinfo not supported" errors:

/opt/trunk$ svn merge --reintegrate ^/branches/v8.5-ruby22rails42
svn: Abfrage der Zusammenführungsinformationen wird von »file:///.../branches/v8.5-ruby22rails42« nicht unterstützt

Would a svnadmin upgrade fix this error? I do not want to update the SVN utilities on the server right now because the SVN repo is accessed by a lot of other tools too.

If not:

(How) can I just rename trunk both on the SVN server and my git-svn local repository and use my branch as the new 'trunk' and so avoid the tedious merge process in SVN altogether? How would I tell my local Git repo to keep track of this renaming process? This may require all clients to discard local checkouts and re-check out the new trunk, but that would be acceptable.

If this is not possible or desirable, how do I avoid the mergeinfo error above using Subversion 1.6.17 and successfully merge my branch into trunk? I can then create a new branch from the last commit before the merge and keep this as my "v8.4-rails3ruby19" branch.

Jens
  • 1,386
  • 14
  • 31

1 Answers1

0

I might be missing something in your context, but normally you do not want to replace the original tag but rather succeed it. What I would probably consider at your place is something like the following sequence:

  1. Tag the current trunk or/and create a quick fix branch /branches/v8.4-ruby19rails3

  2. Merge your branch into trunk. Either via svn or git/git-svn

e.g. the following sequence will squash all your works at your branch and put it to trunk:

git svn fetch
git checkout svn/trunk
git merge --squash ruby22rails42
git commit -m "Merged ruby22rails42"
git svn dcommit
Mykola Gurov
  • 8,517
  • 4
  • 29
  • 27
  • If I had only git to worry about I would just have merged. However, upstream is (still) SVN, and SVN doesn't want to merge for some reason (see error above) and I don't want to lose the merge history in SVN or Git repos. The advice I got by googling around for "git svn merge" all say to do the merging in Subversion, otherwise information will be lost ... – Jens Dec 18 '15 at 21:16
  • Git-Svn discourages merges and favors rebases. If you don't want your history to be lost you can try `git svn rebase` and then `git svn dcommit`. Unfortunately, the rebate may be not as smooth due to the merges from trunk (as opposed to rebates). If this doesn't help you can always go svn low level: see `svn cp`. – Mykola Gurov Dec 19 '15 at 00:56
  • I went ahead and upgraded the SVN metadata format to allow mergeinfo, then merged using plain SVN. There were some backwards changes I had to undo afterwards, but it was not much. So just using plain SVN merge for this kind of task is probably the best solution. – Jens Dec 27 '15 at 22:14