On Wed, 2009-09-02 at 13:28 +0200, Neels Janosch Hofmeyr wrote:
> 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.
Agreed, both the theory and the current practical nastiness.
> 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??
The user knows how to see what the local edits are: "svn diff" or the
interactive equivalent. That's fine. It might be a bit "over the top" to
summarize the local edits automatically as part of a tree conflict
description.
> 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
You mean "the property conflicts", I assume.
> should be integrated with their tree-conflicts, and resolving should also be
> aware of these situations. It's complex.
Well, we can separate it into a basic part and a complex part. The
simple tree conflict resolution options should be the same as for a file
or a property: choose their tree or my tree. That's the basic part.
Ideally we'd have an option to use a three-way merge tool that's capable
of handling svn properties as will as a directory tree of files, but
such a tool doesn't exist unless Tortoise or one of the GUIs has written
one. It is in such a tool that clashes between properties with the same
name in "their" tree and "my" tree could be resolved. It should also
support moving, renaming, deleting, etc. within the resulting output
tree in order to support any possible resolution that the user might
want. That's a lot of potential complexity in there.
In the longer term, we should look at supporting an interface for
plugging in such a three-way directory merge tool. (We might need an
"svnpatch" format to effectively communicate the results of this tool
back to svn.)
I don't think we need to implement such a directory-merge tool in "svn"
any time soon, even though it would be great if we did. Let the user
postpone and use manual resolution.
> 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...
Great. Thanks.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2390147
Received on 2009-09-02 13:55:09 CEST