See this blog post: http://blogs.collab.net/subversion/2010/11/resolving-tree-conflicts
On Thu, Jan 20, 2011 at 8:38 AM, Steve Cohen <sco...@javactivity.org> wrote: > On 01/20/2011 05:19 AM, Stephen Butler wrote: > >> A 'C' in the third column indicates a tree conflict, while a 'C' in > > Thanks, Stephen. > > While we're on the subject, can you tell me succinctly what is the exact > definition of a "tree conflict"? This used to drive me nuts when I used the > subclipse plugin. I got these all the time and I could never understand > them. I've now switched to the subversive Eclipse plugin which is even > worse for merging (I've never been able replicate with it merges that are > simple on the command line) but better in other respects, and have fallen > back on a strategy of doing all merges on the command line which seems to > produce better results for the most part. > > Both plugins assume a great deal of knowledge about the merge process and > their "documentation" is restricted to inadequate explanations of what each > widget in the plugin does, without explaining in real-world terms i.e. in > use cases: When you have scenario x you want to do y, etc. > > The command line is better documented but even here as we see, there are > holes. > > This question was sparked by the following scenario: > > I had made a relatively small number of changes in a branch for future > development. Among these changes were the additions of several new source > files. As I was doing so, a higher-priority defect emerged in production > which had to be resolved immediately. I made these changes in the trunk. > Naturally, I wanted to merge these changes into my branch. However, no > version of the merge command that I could come up with resulted in a > situation that did not want to delete the newly added files. My final, > unsatisfactory conclusion to this mess, was to do the merge and before > committing, revert the files that it wanted to delete. > > I have a feeling that this was wrong, and that down the line, some future > merge will go badly. > > Steve > -- Thanks Mark Phippard http://markphip.blogspot.com/
