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.
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.
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.
> 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.
Received on 2016-06-13 12:50:22 CEST