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
