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.
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.
Received on 2017-02-04 14:12:52 CET