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 <scohen_at_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/
Received on 2011-01-20 14:43:39 CET