grab
OK, thanks Scott - guess there isn't a way to do what I'm after, then. What a bummer.
It's not so much "philosophically appealing", it's that it's a unnecessary, time-wasting PITA. :( Consider the alternatives:-
1) I select a hypothetical "Rebranch" option. All files on my branch which don't correspond to the selected branch source (most likely head of trunk) get overwritten - this is a small subset of the whole tree, so doesn't take too long. I don't lose my object files. (Luckily I don't need any tweaked build config files, but I've seen setups which have tweaked config files in working directories, and in that case I wouldn't lose those either.) Carrying on working with my new copy is just a case of running "make", at which point only the replaced files get recompiled. Total time, maybe 1 minute at most. But we can't do that, because the SVN coders wanted to show how clever their 3-way merge was.
2) I select "delete" on the working copy of my branch. I commit. I lose all my object files (and any tweaked build config stuff). SVN whirs for a couple of minutes before deleting everything. I select "branch" on the trunk and tell it to put the branch in the same place. SVN whirs for a couple of minutes again. I update the location for this working copy. SVN whirs for a bit longer while it recreates the working copy. If I had a tweaked build config, I'd now need to set that up. And running "make" now will rebuild the world. On my current project, this exercise will take maybe 5 minutes because it's only a small system; at my previous company doing mobile phone stuff, it'd take 15 minutes just to retrieve the branch and 3 hours to do a full rebuild, which would be bad news. And this seems to be the method SVN is forcing on me.
3) In the repo-browser, I select "delete" on the branch URL, rebranch to the same name, and update my working copy. In theory that might avoid too many changes on the working copy. Nice idea - except that when I tried that, SVN got totally confused and wouldn't unlock or clean-up the directories or anything. Only way forward was deleting the upper-level directory and starting from cold.
4) Create a new branch from the trunk and switch the working copy to that. It works - except the old branch is still hanging around, the working copy directory no longer corresponds to the URL which can make maintenance more tricky, and I'd still want to delete the old branch at some point which is more tricky (checking out a working copy and then deleting it could be a slow process as per (2), and with the problems in (3) I don't rate the repo-browser's chances).
5) I say "forget this screwed-up branch/merge rubbish". Export from trunk to the working copy, commit it as-is, and never mind the fact that I've now lost version traceability. If I want to add version traceability back to the source, I could also do a merge with "Only record the merge" checked to add the links.
Any good options in there? Well, the first one works for me - but we can't do that. All the others suck to some greater or lesser degree. I could understand this if I was doing something totally out of the ordinary, but this is such a standard day-to-day way of running software development that I can hardly believe SVN would be missing it. It's like building a beautiful car and then telling the driver "By the way, you go round corners by getting your passengers to all lean on that side". :?
grab
That's exactly what I'm doing.
OK, I'll take it from the top, and maybe people can spot if there's anything I've not tried.
My repository. I have an updated working copy (fully recursive) of my private branch with no uncommitted changes. I have a trunk from which I branched my private branch at some previous revision. No-one has any file locks on my private branch. And all I want to do is have all file versions on my private branch updated with the versions from the trunk.
With TortoiseSVN, I select "Merge" and select "Merge a range of revisions". I then enter the URL of the trunk. The "Working copy" is pointing at my working copy of my private branch. I leave the revision range field blank. I select a merge depth of "Fully recursive" to get everything on trunk regardless of what's in the working copy. Result: TortoiseSVN barfs with the error "Working copy path 'util/fcim_a.io' does not exist in repository", where this file is one that's been added to trunk since I branched.
OK, let's try again. Same as before, but this time "Ignore ancestry". TortoiseSVN now throws up a whole bunch of conflicts.
Try again. Look at the log for my private branch, find the repository revision where I originally branched, and enter the revision range "208-HEAD" in the revision range field (where 208 was the revision where I branched). "Fully recursive" on, "Ignore ancestry" off. TortoiseSVN throws up a bunch of "skipped missing target" errors for files that exist in the branch, trunk and working copy.
Try again. Same as before except with "Ignore ancestry" on. Conflicts again on files that have been modified on the private branch (which I'd like to be blown away by the trunk versions).
Checking the docs, I saw that if you hold down the shift key, you get a "Merge all" option. Tried this for the top level of the working copy, with and without "Fully recursive" and "Ignore ancestry". Result - no changes anywhere in the working copy. "Merge all", my arse.
As far as I can see, I've tried every permutation of options. I therefore suspect that this is NOT "possible". And I defy anyone to describe this as "easy", given the f***ing ridiculous, timewasting exercise I've just gone through! :-/ Sorry dude, this isn't aimed at you personally, it's just my frustration with this tool.
I could understand it if I was a fresh graduate doing something stupid or unusual, but I've been in this game 15 years now in a number of different companies with various version-control systems, and in my experience what I'm wanting to do should be a trivial, everyday operation. As a sign of my frustration, I'm starting to think longingly about VSS, and that's a pretty good indication that something is *really* screwed! Grrrr....