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

Reply via email to