On Tue, Nov 18, 2008 at 04:46:30AM +0100, Neels J. Hofmeyr wrote:
> Julian suggested that it would be feasible to disable tree-conflicts
> detection upon update and leave it in for merge (I'd think it's possible
> within very short notice, a couple hours for this one). TC on update are
> inherently more complex than merge, because they need to take care about
> updating the base or not. Update holds the bulk of bugs/problems. Merge is
> simpler as it only results in local mods.
Still, do we know whether any possible merge conflicts can always
be resolved? And that they can always be resolved without requiring
an extremely rare diamond from a cave in South America, waterproof
gloves, a piece of rope, and a strawberry-flavoured lollipop?
> I like what Mark said:
> - Tree-conflicts do look good in many cases, and
> - Tree-conflicts are *very* complex and may need to grow gradually beyond
> 1.7 anyway.
Yes, but a known-working resolution user interface would be highly
desirable for release.
> It remains inherently difficult to form a firm opinion on it. I keep swaying
> both ways... I think it'd be best to have preferably unknowing people to
> take on tree-conflicts scenarios, as stsp tried, and see what they say (see
> the thread following
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=145317
> ), in order to get very specific reasons for either decision.
>
> For example, it would be very helpful if any developers out there could take
> the current trunk and carry out two complete, typical conflicting Java code
> refactorings, and try to merge them either via "merge" or via "update",
> including all resolve/resolved/revert steps necessary.
+1
In addition to having an infinite number of monkeys walk through possible
tree conflict cases to uncover bugs and improve the user interface flow,
we should also try to think of ways to make sure conflicts are always
resolvable, no matter what the situation at hand, e.g. by making certain
guarantees about information available to the user.
Git handles this nicely. See Section "5.2 Detailed results for Git" in
https://www.mi.fu-berlin.de/wiki/pub/SE/ThesesHome/thesis-tree-conflicts.pdf
for some examples.
Here's one:
CONFLICT (delete/modify): alpha deleted in HEAD and modified in \
2cc725a7db86d3f6b05c4060924142aa5ec314d8. \
Version 2cc725a7db86d3f6b05c4060924142aa5ec314d8 of alpha left in tree.
Automatic merge failed; fix conflicts and then commit the result.
[...]
$ git status
alpha: needs merge
$ ls
alpha beta epsilon/ gamma/
$ cat alpha
alpha, modified
$ git ls-files --unmerged
100644 4a58007052a65fbc2fc3f910f2855f45a4058e74 1 alpha
100644 bdbcaf36d1d757776eed566cac34641de540ee83 3 alpha
$ git cat-file blob 4a58007052a65fbc2fc3f910f2855f45a4058e74
alpha
$ git cat-file blob bdbcaf36d1d757776eed566cac34641de540ee83
alpha, modified
I'd say as long as we make sure that the user knows which versions of
files involved are relevant and that the user can always get at these
versions of the files (and run 'svn diff' against them, for example),
there's not much of a problem.
See also http://subversion.tigris.org/issues/show_bug.cgi?id=3322
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-18 14:06:32 CET