On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <s...@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
