On Wed, Feb 27, 2013 at 3:44 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> In my current project, I created myBranch a long time ago. I am working on
>> some independent code which doesn't require accessing the other developer's
>> code. The other developers have branched and merged several times in the
>> meantime. Their current branch is different from the original branch from which
>> I created myBranch. Also, their code has been severely reorganized, with many
>> folders removed and others added.
> The tool can only do so much. If you expect to merge branch changes back to the origin you have to keep the branch up to date. Every day that goes by without merge in from the origin is going to make it more difficult when you do finally move. So, rule number one with feature branches, merge early and merge often.
My suggested solution would be to do incremental merges.
Go "back in time" and merge all versions up to just before the first
directory restructure into your branch. Commit. Merge the directory
restructure. Commit again. Repeat until you have merged all changes.
This should be a much more manageable merge than trying to do it all
at once. I actually had to do this in ClearCase more often than in
SVN. SVN's merge capabilities are actually much better for files as
far as I've seen. Especially, if you install an external merge tool
like KDiff3 or Beyond Compare.
My team also recently switched from ClearCase, and I have found it a
HUGE improvement. The ONLY things ClearCase did better, in my opinion,
1. Merge tracking (including merge arrows in the version tree)
2. Following through history and merging of file renames (the issue
you're running into)
3. Making money for the owners of ClearCase, from license and support fees
Everything else is needlessly complex, locked-down, or just plain
broken; with tons of room for user error in every step of the process.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-28 17:45:10 CET