Rob Davies wrote:
> [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.
Hmmm - TSVN uses the svn_client_status() API function to get the paths
to the conflicted files. The question is now if that API function should
return the paths to the new files or to the old ones...
Those paths I'm talking about are returned in the status struct
status->entry->conflict_new
status->entry->conflict_old
status->entry->conflict_wrk
> I'll post this on the TortoiseSVN dev list and see what they reckon.
I'm reading this list too ;)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 8 19:28:12 2004