Merge: how to replace an old working copy with trunk
Hi, I'm having a bit of a problem with SVN merging, which I'd appreciate some advice on. I've done a bit of a search round here for previous posts which might answer my question, but couldn't find anything. My client is TortoiseSVN, and both Tortoise and the SVN server are at version 1.5.0. BTW, I've also served time with VSS, Perforce, CVS and ClearCase, so I'm not exactly a version-control newbie, just new to being Subverted. :-) As usual, we have the trunk with our latest-and-greatest code, and I have a personal working branch which was branched off the trunk at some time in the past. I've done various ad-hoc merges from the trunk, and made a few of my own changes to branched files which I've then merged back onto the trunk. I'm now at a stage where my working branch is significantly out-of-date, so I'd like to blow away everything currently on my working branch and replace it with the latest-and-greatest from the trunk. So far, so normal. And merging would seem to be the SVN way to do this - I can't branch because I've already got a branch there. But Tortoise (and/or SVN?) doesn't let me do this, as far as I can see. There is no merge option we (all engineers in the room) can find which will let me say "never mind what's on my branch now - give me the latest version, dammit!" Instead, it tries to be clever and compare previous changes on the branch against previous changes on the trunk, which is not at all what I want. As expected, this throws up a bunch of conflicts, and some of the allegedly-unconflicted auto-merged files are plain wrong. But all I want is a straight copy - no fancy merges, no conflicts, no cleverness at all, just a straight replacement of branch with trunk. Can I do it? Not as far as I can figure out. Sure, I could export from the trunk and file-copy it over my working branch, or I could delete my working branch and rebranch from the trunk with the same branch name and directory location. But both of these are hacks which are avoiding the basic problem: either I/we don't understand SVN's method for doing this, or SVN (and/or Tortoise) plain doesn't let me do it. I'm hoping it's the former, so if anyone can point me in the right direction, that'd be great. But if it's the latter, I'd be disappointed with SVN for lacking such a basic feature. Please can any SVN wizards shed any light on this? Cheers, Graham.
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". :?
Re: Merge: how to replace an old working copy with trunk No, it's very possible and easy (if I'm understanding you correctly). 1. Go to your private branch in your working copy and update it. 2. Now if you want to undo any uncommitted changes, do an svn revert. 3. Now do your merge. The merge should be as follows: From:
To: HEAD revision
The result of the merge is stored in the working copy at:
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....
1-5 of 5
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.