On Fri, 2010-01-22, Daniel Näslund wrote:
> [[[
> Design spec for tree conflict resolution in the commandline client
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The hard part is figuring out in what state the wc is in during the
> different user cases.
>
> The main difference between update/switch and merge is that we don't
> have somewhere to store the incoming changes during a merge. It would be
> nice if we could save a THEIRS tree.
>
> ### What if we have more than one conflict at a time? One at the top of
> ### a tree and another nested below. Can that happen?
We intentionally disallow that. Comments at the top of
subversion/libsvn_wc/update_editor.c try to explain that but the
comments may be a bit too terse.
> Contents
> =========
> Problem definition
> Requirements
> Use cases update/switch
> Use cases merge
> API changes
> User interface
>
> Problem definition
> =========================
> Users are having problems understanding how to resolve tree conflicts.
> For some operations they may not know how to get back to a previous
> state. They don't always know how to view the changes causing a
> conflict.
>
> Requirements
> =====================
> It should be easy for the user to understand why the conflict has
> happened and how to resolv it.
>
> Update, switch and merge should be reversible. That is; going back to
> the former revision in the wc should restore the contents to the
> original.
>
> The solution should work for both files and dirs.
>
> The resolver should not handle moves since we have no way to track
> those. When I say handle moves I mean "do something about the other end
> not affected by this conflict". We will apply give the option to apply
> changes elswehere and do renames but we will leave some files behind for
> the user to clean up.
>
> ### There should be a good way to view what has caused a conflict.
> ### Perhaps some info from 'svn info'.
>
> The tree conflict resolver interface should be consistent with the
> existing resolver. It should provide
> {postpone,theirs,mine,diff}-options.
>
> ### The user should be able to run the conflict resolver at any time.
> ### We have to fix libsvn_wc/conflicts.c first. Not really
> ### specific to this feature.
>
> Use cases update/switch
> ========================
> Since we don't know how to follow moves we just leave the add-half as
> is. The user can remove it manually. Once we have editor-v2 this would
> work automatically.
When you say, "leave the add-half", I think that only applies to the use
cases where the "delete" half is in conflict. In use cases where the
"add" half is in conflict, we will just leave the "delete" half.
> ### Will it be awkvard to leave the add-half? Will the
> ### user understand what has happened?. I'm not sure I would!
We can improve that in a later enhancement.
> Local add, incoming add
> -------------------------
[...]
Sorry, I haven't had time to read the rest of this document yet.
- Julian
Received on 2010-02-05 19:08:29 CET