Interactive conflict resolver issues

[Julian Foad <ju...@btopenworld.com>]

Some things that need doing for interactive conflict resolution:


* conflict_status_walker() calls the resolver callback and then ignores the result->merged_file part of the result.  That means certain confict resolutions will appear to succeed while silently choosing the wrong version of the text or props and discarding the version that the user created.


* Resolving of individual prop conflicts

  - Fix UI prompting for a prop conflict: it needs to show just the conflict on that property.  (Right now it shows all prop conflicts on that path every time it asks about one of them.)

  - Marking an individual property as resolved is not yet implemented by svn_wc__resolve_conflicts() -- the 'const char *resolve_prop' parameter is not yet allowed to be a property name.


* Fix prop conflict inconsistency: read_prop_conflicts() puts the conflict description file in the 'theirs' field, while generate_propconflict() puts 'their' value in the 'theirs' field.  That has something to do with legacy WCs upgraded from 1.7 to 1.8: in that case only the .prej file is found in the conflict storage in the WC, but svn_wc_conflict_description2_t doesn't have a dedicated place to put that.  Suggestions below.

* Improve the conflict_desccription2_t struct for a prop conflict: old/theirs/mine should be property values not paths to files.


* Testable prompting (via a stream?)

  - Need to be able to write automated tests for interactive conflict resolution.  Accessing the 'terminal device' from a Python test is probably hard, and whether it actually uses the terminal is not the most important thing to test.  So can we make the prompting use stdin/stdout while running the test suite?


ACTIONS (in addition to obvious fixes)

Rev svn_wc_conflict_description2_t.


It's not clear to me whether we intend to keep providing the '.prej' file for prop conflicts.  If not, instead of trying to cope with the possibility that some conflicts stored in the WC have just a .prej file because of coming from an upgraded old WC, can we change the upgrade code to do *something* (almost anything) in the way of turning the old conflict description file into some kind of indication that uses only the new scheme.  Even if it doesn't preserve the data properly (or at all).


- Julian


--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download