On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
>> To be honest, being able to use the python test framework would be a
>> lot more productive for me. Maybe I can look into how to make it
>> handle interactive prompting? Unless there's a reason why this would
>> be notoriously difficult to implement?
>
> One reason which makes this difficult is that 'svn status' and 'svn info'
> do not show the new conflict descriptions. They still show the same data
> as they did in 1.9. This allows me to avoid updating test expectations
> for a ton of existing python tests.
Ah okay. I suppose 'svn status' and 'svn info' will show the new
conflict descriptions eventually, but just not right now, and that
this might be a moving target (the exact wording etc.) for a while.
Okay, that may make it difficult to program tests against.
> So the python tests would have to run 'svn resolve' and parse the description
> of the conflict from English sentences. This could be done, but it's not
> going to be easy to maintain. I expect us to keep tweaking and refining
> conflict descriptions over time.
>
> Whereas the public C API is already "frozen" so it's possible to write
> a test once and have it working "forever". The hard part is all about
> getting the working copy into a conflicted state.
> The steps beyond that is almost identical in each test:
> - resolve the conflict (same API call everywhere expect for the option ID)
> - make sure the working copy has the expected status
>
> So I would guess that while the C tests are a bit more work to write
> they will pay off much better during long term maintenance.
Okay.
> Caveat: The interactive conflict menu is not automatically tested.
> But it never has been. And while some small mistakes did slip into
> released menu code in the past there hasn't been a serious problem.
>
>> Does this mean that none of your new resolution options can / will be
>> applied automatically (hard-coded or optionally by some configuration
>> or "conflict resolution policy" thing)? Like incoming move upon an
>> edit?
>
> The API allows the client to select an option so the decision is entirely
> up to the client. Different clients could do different things here.
Ack.
>> I'd like this to become available someday, but maybe it can be out of
>> scope for 1.10, something for later on ...
>
> I'd like to see how interactive resolution works out. I don't want to
> cut the user out of the loop, especially in situations where we use
> heuristics as we do with incoming moves. Perhaps later, once certain
> options have "proven" themselves, and/or if many people ask for it,
> we could execute certain options by default. But I believe the default
> should be interactive prompting, at least for now.
>
> For 1.10 we could try to add a configuration option somewhere in
> ~/.subversion which allows users to pre-select options for some conflicts.
> It's not trivial though, because the configuration directives would need
> to match a particular conflict and I'm not sure how exactly that could be
> expressed in the 'ini'-style syntax of our existing config files.
> It also pushes a configuration burden on our users. Instead of answering
> questions they'll be editing the config.
>
> Or we could add a single toggle for 1.10 that enables 'smart' resolution which
> would pick certain options automatically where we believe it to be appropriate.
> This could either be some kind of 'svn resolve --be-smarter-than-me' command
> line option, a configuration file option, or both.
> This would be pretty easy to implement, but we'd have to make good guesses
> as to what is a 'smart' thing to do in a given situation.
> And we'll have to consider what could happen when heuristics get it wrong.
Okay, sounds like a good approach. I don't have anything to suggest
for this right now.
--
Johan
Received on 2016-06-14 22:14:55 CEST