On Tue, 2008-11-18 at 14:06 +0100, Stefan Sperling wrote:
> 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 don't think we have any restriction on the use of "merge" or
"revert" or "resolved".
- Could be difficult to remember/discover the source URL(s) and
revision range. Issue #3322 would help a lot.
- That's all I can think of for theoretical concerns. Need to try some
more walk-throughs to check for practical problems.
> > 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.
Indeed. OK, from our IRC exchange just now we're talking about ensuring
users have the pertinent info (incl. URLs and revs involved - issue
#3322) and hints in messages of what they may need to do.
Preferably we'd have "resolve --accept=old/theirs/mine" but I think
that's too ambitious for 1.6, despite being highly desirable.
> > 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.
> 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
> 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
> $ 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
Yeah... That's looking important. Changed the issue's priority and
milestone to 2 and 1.6-consider.
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 20:07:58 CET