I'm looking into enabling 3-way conflict markers for property conflicts.
Consider the following case:
In ... the property's value is...
====== ==========================
BASE 'local'
WORKING (deleted)
Merge-LHS 'repos'
Merge-RHS 'repos.changed'
Right now, if the code is switched to
svn_diff_conflict_display_modified_original_latest, it will generate:
"Trying to change property 'edit.del'\n"
"but the property has been locally deleted.\n"
"<<<<<<< (local property value)\n"
"||||||| (original,older diff3 version)\n"
"local=======\n"
"repos.changed>>>>>>> (incoming property value)\n",
Shouldn't the output in that case be:
"Trying to change property 'edit.del'\n"
"but the property has been locally deleted.\n"
"<<<<<<< (local property value)\n"
"||||||| (original,older diff3 version)\n"
"repos=======\n"
"repos.changed>>>>>>> (incoming property value)\n",
?
Daniel
---
That function has some interesting logic around those BASE and Merge-LHS values:
/* Pick a suitable base for the conflict diff.
* The incoming value is always a change,
* but the local value might not have changed. */
if (original == NULL)
{
if (incoming_base)
original = incoming_base;
else
original = svn_string_create_empty(scratch_pool);
}
else if (incoming_base && svn_string_compare(original, mine))
original = incoming_base;
Here, ORIGINAL is the variable that's eventually passed in the ORIGINAL (aka,
OLDER) version formal parameter of the diff3 API; however, the code sometimes
sets the variable "original" to the ORIGINAL version, and sometimes to the
INCOMING_BASE version.
I don't quite understand this. Why does it make sense to set the variable
'original' to a different value (other than the empty string) if it is NULL?
If one of the four sides of the merge happened to be a nonexistent value, then
that (a null value) is what should be displayed, no? i.e., the function should
either always set the variable "original" to the ORIGINAL version,
or always set that variable to the INCOMING_VERSION version. Does that sound
right?
Daniel
