Merge branch from trunk into newer branch from trunk, resolving directory conflicts
From: derek fong <fong_at_subtitled.com>
Date: Thu, 2 Dec 2010 01:50:09 -0500
Hello,
Here's my scenario, hope someone can help me out with it:
I created a branch (b1) from trunk several months ago. Since then, my branch has undergone active development while the trunk has undergone a couple of relatively minor revisions.
My team later created another branch off of trunk several weeks after mine (b2), and began refactoring code... directories got moved around, and files got added, renamed and deleted on this new branch.
I now want to merge the changes I've made on my branch (b1) to my team's branch (b2) so that we can all resume working on the same branch (b2) with my changes merged into theirs, but am not quite sure how to go about this. I obtained the revision number of trunk when I created my branch (r500), then proceeded to do a three-way merge that looked something like this:
% svn checkout repo/branches/b2
This appears to work at first, but since some directories have been moved + removed from b2 and some of my work on b1 occurred in one of these deleted directories, Subversion throws the following conflict on the directory ("application") that was deleted from b2 during the refactoring:
[fong_at_localhost] ~/sandbox/temp/_merged/repo: svn stat
I think I understand why that's happening, but what's the best way for me to retain the history of the files in "application" that are now scheduled for deletion following the merge? Do I need to accept "application" as deleted, then manually "svn copy" files and directories from b1 into their new refactored locations on b2? It seems there should be a better way to do this, but I'm stumped.
Thanks,
-f-
-- Derek Fong Web Application Developer subtitle designs inc. <http://www.subtitled.com/> "Mistakes are the portals of discovery." --James Joyce >> GPG key/fingerprint available upon request <<Received on 2010-12-02 07:50:49 CET |
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.