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?
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!
Received on 2013-05-14 11:16:37 CEST