Re: wish for new API or extended one

On 04.02.2017 14:12, Stefan Sperling wrote:
> On Sat, Feb 04, 2017 at 01:45:10PM +0100, Stefan Kueng wrote:
>> On 04.02.2017 11:16, Stefan Sperling wrote:
>>> On Sat, Feb 04, 2017 at 09:23:06AM +0100, Stefan Kueng wrote:
>>>> Hi,
>>>>
>>>> while trying out the new conflict resolver APIs I came upon a slight
>>>> problem. The API svn_client_conflict_option_get_description() returns a
>>>> string that can be used to show to the user as a choice - in TSVN that would
>>>> be the text on a two-line button (the 'label' is the first line, the
>>>> 'description' the second line).
>>>>
>>>> The problem I'm having now is that the description is always the same, even
>>>> if there are multiple 'moved-to-candidates' available. And if we use another
>>>> than the first moved-to-candidate, the description mentions the wrong path.
>>>
>>> So you're calling svn_client_conflict_option_set_moved_to_repos_relpath()
>>> and if you then get the description again the path isn't updated?
>>> That would be a bug.
>>
>> No, I'm not setting the path to the options object yet: I do that *after*
>> the user clicks the corresponding button.
>> Is it allowed to call
>> svn_client_conflict_option_set_moved_to_repos_relpath() multiple times on
>> the same options object? The docs don't mention that so I assumed no.
>> Also, is it possible to 'remove' such a set path again? Just in case the
>> user wants to do another action than setting a path.
>>
>> If all answers are "yes", then I can just set the path, get the description
>> and then later set another path if necessary before resolving the conflict.
>>
>> Stefan
>
> The idea is to just call it as many times as you want to.
> It just sets an internal index that indicates which moved-to-path to use
> for descriptions and resolution from now on.
>
> You cannot 'remove' the path. Currently, if a move is detected we force
> the user to choose a move target. Perhaps the API should account for the
> possibility where the user decides that this is not a move after all?
> With the current API you could work around this limitation by discarding
> the conflict object, then get a new one and do not call get_details() on it.
> This new conflict will offer the "accept/ignore deletion" options only.
> But that's not very pretty.

But even if you force the user to chose a move path, the options
"Postpone" and "Mark as resolved/accept current working copy state" are
still available?
What happens if you set a move path index but then decide on plain "Mark
as resolved"?

As for geting a new conflict object: doesn't this ask for a
svn_client_tree_conflict_object_duplicate() API?

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net