On 7/26/2016 5:51 PM, Stefan Hett wrote:
> On 7/25/2016 8:29 PM, Stefan Küng wrote:
>> On 25.07.2016 16:35, Stefan Hett wrote:
>>> I'm currently trying to debug/trace down the following error I get when
>>> clicking the "Prefer local" button on TSVN's resolution dialog upon a
>>> binary file conflict during a merge:
>>> Would you have any hint for me for the location which would be related
>>> to the produced error message: "Conflict on [...] could not be resolved
>>> because the chosen version of the file is not available."?
>>> I'd like to trace down what's the cause for that on my machine/in my use
>>> case to either understand the current behavior or properly report the
>>> problem to the appropriate list (aka: TSVN or SVN).
>> That error message is generated in the file
>> subversion\libsvn_wc\conflicts.c in the svn library, function
>> When you chose "prefer local" you get the path in the switch-case going
>> through svn_wc_conflict_choose_mine_conflict - which calls
>> merge_showing_conflicts(), but that function should set
>> 'install_from_abspath' as well unless there's an error creating the
>> merge file.
>> Not sure why you get that error. From a quick view of the code that
>> shouldn't happen, but it may be something with your setup/merge.
>> You'll have to ask on the svn mailing list for details about this.
> Thanks for the pointer Stefan. I've discussed the issue with Bert and
> stsp on IRC and proposed a patch for SVN to resolve the problem (see:
> "[PATCH] Fix a conflict resolut" on SVN's dev mailing list).
> As far as I understand the code there the issue should be present in all
> cases for binary file conflicts. I wouldn't understand how it cannot
> trigger in any situation.
> As far as I've been explained the design on that side, mine_abspath
> would never be set for binary files, since SVN only generated its auto
> generated merged files only for non-binary files. Hence
> install_from_abspath should always be NULL in these cases (aka: when
> talking binary file conflicts).
> Let's see whether the patch (or some variation) gets accepted.
To conclude this thread: The fix got in SVN 1.9.5 and hence is also
fixed for good as of TSVN 1.9.5.
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-12-31 03:02:46 CET