Mark Phippard writes:
> In the above scenario, when each pass of the merge runs it is possible that
> one or more conflicts are created from the merge. If any conflicts are
> created, then merge can finish the current pass it is performing, but it
> cannot continue on to do the next pass unless those conflicts are resolved.
>
I see No reason why the whole merge process needs to stop just because
a subtree (possibly just a file) has conflicts. We just need to exclude
that part of the tree and notify the user.
> Of the two solutions, I think I prefer the first one for usability because
> it offers the best environment for resolving the conflicts. But in general
> it still sucks. The user needs to potentially run the process many, many
> times to finish the merge. If we adopted this approach as our likely path,
> then I think we would want some kind of information or callback when the
> merge aborts where we could provide the user a reasonable explanation of
> what we have merged so far and what they need to do to continue. That would
> help usability somewhat.
>
Agreed.
> I think I hate the second solution. First, I think that resolving conflicts
...
> than the first option. I just think the notion of a long running process
> somewhat randomly throwing dialogs at you would not make for a good
> experience. Consider, the merge process could easily run for 10 or more
> minutes, then ask you to resolve some conflicts, then run for 10 or more
> minutes and ask you to resolve some more, then run for 20 more minutes, etc.
>
I see my "merge and go for a coffee" argument reappearing;)
(See an earlier thread discussing interactivity.)
I think it should be possible to push the questions towards the end
of the process by excluding problematic subtrees and continuing merging
as sketched above. I'll try to write up my idea of the augmented merge
algorithm in a sparate thread. But you're right about the general problem.
That's why I'm opposed to interactive merge conflict resolution in the
cmdline client by default. I think we need to support the user bailing out
to resolve conflicts and restart the merge to continue where it was *and*
have conflict callbacks to support conflict resolution in the process.
> Finally, in either solution, an inconvenience exists that a user could be
> resolving conflicts in areas of code that are going to be removed in later
> stages of the merge.
Yes, this is a problem that has bugged me for a while.
Maybe this is solvable if there is a way to avoid getting the information
for paths that are going to be deleted. I don't know if svn diff --summarize
could be used here. Also, the sparse-directories branch has the notion of
depth that could be useful.
What I'm trying to say is that our current approach doesn't have
to be as bad as you suggest, but it is still not as good as we'd want it.
I'll try to summarize the 1.5 merge algorithm in another mail.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 7 13:37:19 2007