props during tree-conflicts -- was: svn commit: r39054 - branches/1.6.x

Stefan Sperling wrote:
> * STATUS: Add r39052 to the r38000 group.

[[[
+ ### A/B/E gets both a property and tree conflict flagged. Is this OK?
]]]

IMHO, in theoretical terms, it isn't.

The picture is this: On the left, I have a directory with some properties. I
delete that directory along with its properties, and create a new one with
different properties.

On the right, I changed a property, not aware that the whole directory was
being replaced.

By coincidence, a new property on the left has the same name as the modified
property on the right.

The tree-conflict is "a level higher" than the prop "conflict". The property
mod is in fact the reason for the tree-conflict. But, with interactive
conflict resolution, the user is *first* asked to deal with the property
conflict and is told only later that the entire directory was in fact being
replaced. That's not very nice.

But in practical terms, we have no way of telling the user "a property mod
was the reason for the tree conflict". We simply say "local edit" -- another
design hole. So right now, also flagging a prop conflict is the only way??

Note that, when a property mod was the reason for a tree-conflict, there
usually isn't a prop conflict appearing along. That only happens when the
incoming changes also modify/set that same prop. Should be cleaner.

Has anyone made up their minds yet on how property changes during / causing
tree-conflicts should be treated? It should be visible that the local edit
was not a text mod, but a prop mod, or maybe both, etc., the property mods
should be integrated with their tree-conflicts, and resolving should also be
aware of these situations. It's complex.

Anyway, this white blob on our map should not prevent backporting the 38000
group. That fix is intended first and foremost to prevent breaking the WC
during replace with TC. Reviewing the rest of it now...

~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2390140