Stefan Sperling wrote:
> On Mon, May 13, 2013 at 10:10:58PM +0100, Julian Foad wrote:
>>> Author: stsp
>>
>>> URL: http://svn.apache.org/r1480669
>>> Log:
>>> If a merged property value exists, make the 'dc' conflict prompt
>>> option use the merged value as 'mine' for display. Else, users might
>>> get confused if they edit a property, run 'dc', and see the value from
>>> before the edit.
>>
>> Hi Stefan. I see how it could be confusing, but now it is inconsistent
>> with text conflict handling:
>>
>> | text conflict | prop conflict
>> -------------+----------------+------------------------
>> 'dc' shows | original text | edited val
>> 'e' | edited text | conflict hunk with original val
>
> For text conflicts, 'e' shows edited text + conflict markers,
> doesn't it?
> Does your 'edited text' imply the possible presence of conflict markers?
After a previous edit, 'e' simply opens the same file again, so it has whatever text and/or markings you left in it. (The first time you 'edit', the text is whatever was produced by the failed merge attempt, so it has conflict markers in it if your merge tool configuration is the default or similar.) This is different from properties, where each time you choose 'e' it recreates the original conflict, discarding any previous edit.
> In the log message of r1480669, I've hinted at the possibility to show
> the same for prop conflicts in the future, because I'm not 100% happy
> with the current behaviour either:
> (edit_prop_conflict): For now, pass NULL for the merged file to
> merge_prop_conflict(), so that repeated edits always start with
> the same original values. This behaviour can be reconsidered later.
>
>> and also inconsistent with the 'select my version' option:
>>
>> [[[
>> Conflict for property 'p1' discovered on 'foo'.
>> local edit, incoming edit upon update
>> Select: (p) postpone, (mf) my version, (tf) their version,
>> (dc) display conflict, (e) edit property, (r) resolved,
>> (q) quit resolution, (h) help: dc
>> <<<<<<< MINE
>> edited prop val
>> ||||||| ORIGINAL
>> v=======
>> v2>>>>>>> THEIRS
>> Select: (p) postpone, (mf) my version, (tf) their version,
>> (dc) display conflict, (e) edit property, (r) resolved,
>> (q) quit resolution, (h) help: mf
>> [...]
>> $ svn pl -v foo
>> Properties on 'foo':
>> p1
>> me
>> ]]]
>
> Ugh, that's a big ugly alright.
>
>> I'm going to vote +1 on the r1477294 group of back-ports that you
>> proposed, where this change is listed as a 'small follow-up fix',
>> because basically the changes are good and this is just a small
>> inconsistency by comparison, and because the proposal involves a UI
>> change which needs to get into 1.8.0 if it's going to get anywhere
>> soon.
>>
>> But I think we should do something to make this consistent with text
> conflicts, one way or the other.
>
> I agree. We're not going to be able to fix many of the property conflict
> handling quirks for 1.8. I intend to make further improvements for 1.9
> and later, and will keep your points in mind.
>
> Thanks!
Thanks.
- Julian
Received on 2013-05-14 16:53:41 CEST