Replacing branch contents with another branch
From: Graham Bartlett <ratelect_at_hotmail.com>
Date: Wed, 6 Aug 2008 14:56:42 +0000
This is a question I posted on SVNForum.org and didn't get a reply to. I wasn't very complimentary about SVN over there, which might be why - I can only say that I was having a bad day, and SVN woes weren't helping. Anyway, I'll try again and hopefully someone can either (a) explain how to do it, (b) second me in requesting a bugfix, or (c) give me a good reason why I wouldn't want to work this way. If (c), note that "Because SVN can't do it" is not a good reason. ;-)
OK, the situation...
We have a code trunk, into which all the latest development goes. I have a personal branch, branched from the code trunk at some earlier revision, in which I do my own work before submitting to trunk. The plain-vanilla textbook way of using branches, in other words.
During my hacking, my personal branch inevitably acquires a few bodges, workarounds and test point printf's for things I've done along the way. I've checked them in, because we all need access to these bodges while we're looking at what we're fixing. I don't want these hacks to go back into trunk, nor do I necessarily still want them in my branch. They're not a problem right now, but the work I needed them for has come and gone.
As time goes on and other people submit changes to trunk, my personal branch diverges further from trunk, until I decide I need to get my personal branch back to head of trunk. What I'd like to do now is say "merge from trunk to branch", select to merge from head of trunk to head of my branch, and say "replace everything". This would delete files from my personal branch which were deleted on trunk, add any new files created on trunk, and replace any common files with the versions in trunk. I don't want merged versions of files which use merge-tracking to combine changes on my personal branch and changes on trunk; I just want my personal branch to become a copy of trunk and blow away the obsolete hacks in my personal branch.
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.wholebr says that simply comparing one branch tree to another branch tree is "wrong". In many cases it is, but in some cases it's "right" for the job the user's wanting to do. Whilst the merge-tracking feature is very nifty most of the time, sometimes (like this) the user just want a dumb overwrite. As far as I can see, SVN simply doesn't provide this ability. All variations of merging that I've tried have resulted in merge-tracking trying to combine changes on my personal branch with changes on trunk to create a third Frankenstein's-Monster offspring of the two, or alternatively with no changes to the branch at all. (And yes, that was *every* permutation of merge options available in TortoiseCVS - it took me the better part of an afternoon to test them all!)
A workaround is that I delete my entire working branch, commit that, and then rebranch from trunk - possibly using the same name for the working branch, or possibly using a different branch name. That gets me working, but it's a very nasty hack. The most significant problem is that I lose version history from my pre-merged personal branch to my post-merged personal branch, so if I want to check what changed when I pulled down the latest version, that is not possible. A less significant problem but still a deal-killer on many systems is the simple mechanics of doing the delete, commit and rebranch. At my last company, the full tree was about 3GB, so a delete, commit and rebranch would keep your machine tied up for a very long time indeed. On a tree this size, the majority of the files clearly *won't* have changed, so a merge which just took the head-of-trunk versions of all changed files would turn a "forget-about-this-machine-for-the-rest-of-the-day" job into a "2-minutes-anytime-you-like" job.
Does anyone have any good ideas on this one? As far as I can see, I'm not trying to do anything earth-shatteringly different here, so I'm very surprised that this isn't playing ball. Apologies for the lengthy description, but I'd rather give full information at the start, instead of giving people incomplete info and then trying to fill in the gaps later.
This is an archived mail posted to the Subversion Users mailing list.