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.