subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <>
Subject Re: wish for new API or extended one
Date Sat, 04 Feb 2017 13:12:45 GMT
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.

View raw message