Re: Unresolved conflicts and Update

Ben Collins-Sussman wrote:

> On Thu, 2004-07-08 at 10:40, Rob Davies wrote:
>
>
>>The problem is that it allows the update, but doesn't modify the
>><filename>.mine file that is still in existence from the previous
>>update. As a result, the .mine file shows code prior to any
>>changes you made since the first update, and can result in code
>>loss via, e.g., TortoiseMerge if you click "Save" before realising.
>
>
> That's not true, I just tried to reproduce.
>
> If a file is in conflict, and has three fulltext files lying around, and
> then you run 'svn up' again and receive *another* conflict, you end up
> with 6 fulltext files lying around. The original '.mine' file isn't
> deleted or overwritten or touched at all; svn just creates a new .mine
> file with a slightly different prefix:

[snip]

> ...notice that I now have 'eyemodule.py.mine', was was the original file
> before the first conflict, as well as 'eyemodule.py.2.mine', which is
> the file after the first conflict, but before the second conflict. No
> data loss.

Ah! Thanks, Ben... that sheds a little new light on the problem.

Hrm, the difficulty I now have is that both Subversion and
TortoiseSVN are working "correctly", but that Tortoise expects
that any conflicting files will be of the first order conflict
(so <filename>.mine), and so throws *that* filename at
TortoiseMerge, rather than the new .2.mine file.

I'll post this on the TortoiseSVN dev list and see what they reckon.

Thanks for the clarification. :D

-- 
Rob.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org