svn cp -m “copy trunk to branches/foo” svn://my.svn.com/trunk svn://my.svn.com/branches/foo
nothing changed in trunk since then. Now when I try to merge it back (it’s been awhile, so there is a large number of changes – I’m at build 1648 now), I get about 30+ files in conflict (out of hundreds of changes – lots of fun to sift through those in svn status).
If so, then conflicts are really very strange indeed. I am not aware of a way to force the “branch always wins” behaviour you want. You’re essentially wanting to do a copy of the branch back on top of the trunk. When I’ve wanted to do that in the past, I’ve run into headaches.
Alternatively, perhaps doing the merge incrementally? Do the first 1/2 of the changes and see if that works, then the rest. If not, start with the first 1/4. Etc. That way maybe you can at least get a better idea of where things are going screwy. No need to be super-scientific about defining “1/2,” though. Just something like, if your current SVN revision is N, merge up to revision (N - 268)/2 + 268.
That diff from either working copy yields a mess of output.
I might just move the current trunk out of the way, and then copy the branch over as the new trunk. Since I don’t really care about the current trunk (haven’t built from it in months, but I want to get back to a real “trunk” now with this new build), it seems safe…
Basically I need to allow changes to continue in this branch while preserving the current state for minor ongoing production changes (because this branch is going to be a broken build soon, as some massive additions come in… happy fun time).
OK, if that diff yields output, then something (the output of the command), has changed on the trunk since you made the branch. I’d suggest taking a quick peek at the content just to be sure you really don’t want it. Better safe than sorry and all that.
If you decide you don’t want any of those changes, we can brute force things by rolling back the mainline, then doing the merge.
(CAVEAT, the following is off the top of my head and untested. That said, it should get you moving towards where you want to go, anyway.)
Create a new trunk sandbox to play in:
$ svn co svn://my.svn.com/trunk trunk-sandbox
$ cd trunk-sandbox
Revert the trunk changes, whatever they happen to be:
$ svn merge -r HEAD:268 svn://my.svn.com/trunk
$ svn ci -m “revert all trunk changes since the branch at rev 268”
Merge the branch changes back to the trunk. Since the trunk is now back to the state it was in when the branch was created, the patch should apply cleanly now.
$ svn merge -r 268:HEAD svn://my.svn.com/branches/foo
$ svn ci -m “merge branch ‘foo’ back to the trunk”
