As far as i know, two way merge tracking doesn't exist in SVN. The only exception to this is --reintegrate which I guess is two way, but unless I'm mistaken, you can only do it once: you have to blow away the branch once you've reintegrated it.
We prefer a branch-by-purpose model here, but it's quite painful to use SVN with this since in order to merge changes between the various branches (we have a minimum of 3 active branches) you have to cherry-pick the changes manually. Handling tree-conflicts in this environment is quite frustrating. I'm hoping that 1.7 will address much of this... Piers. -----Original Message----- From: Steinar Bang [mailto:s...@dod.no] Sent: Thursday, September 23, 2010 12:02 PM To: users@subversion.apache.org Subject: Re: Why is --reintegrate neccessary? FWIW svnmerge works the way I expected svn merge tracking would work. svn merge tracking doesn't. So I'm still using svnmerge... But one of these days I'll figure out if it is possible to to use built-in merge tracking to my usecase. I've versioned my home directory, and where I end up with a file being present on one machine and not on others (e.g. procmailrc present on the machine I do my maildelivery but not on others), or some other configuration that is hard to do in a machine specific way, I fork. And I would like to be able to merge changes across the forks and track where they came from. And so far svnmerge has been successful with that. I have a MAIN, all branches go out from the MAIN, and I've set up for two-way merging. But I don't know if built-in merge tracking would work for me. I think not. But I'll happily listen if someone explains to me why it can. Thanks! - Steinar
