On Fri, Mar 16, 2012 at 10:31:36AM -0400, Greg Stein wrote:
> > edits manually -- tasks that 'svn' could already have performed on the
> > user's behalf. These manual steps take a lot of time away from users.
>
> Back to a strawman. I never suggested created this difficulty.
>
> Let's focus on flagging a conflict, where one possible resolution is
> applying the edits to the move-dst. Through interactive resolution, or
> possibly with a sweeping command along the lines of:
>
> $ svn resolve . -R --accept=apply-to-moves
The --accept option argument currently applies to all sorts of conflicts.
Arguments that apply to a particular tree conflict case don't make much
sense. Rather, we should map the existing {theirs,mine}-{full,conflict}
options to a particular possible outcome of a given conflict scenario
(the exact list of cases and their possible resolutions are still TBD).
A good interactive resolver could suggest even more options, if not
--no-interactive, and if there is still ambiguity in resolving a
particular conflict because even more possibilities exist than the
options can represent.
However, wanting to use the existing --accept arguments is a goal
we cannot implement properly yet without major effort. One particular
case that is difficult to realise is 'theirs-conflict' for an incoming
move. See here: https://svn.apache.org/repos/asf/subversion/branches/moves-scan-log/BRANCH-README
I don't think expanding the current resolver to cover tree conflicts
is a reasonable plan. We need something better, written from scratch.
So, generally, I agree with everything you're saying. What's clear to me
now is that we've been talking past each other because we're trying
to solve different problems. You want to nail down an ideal design,
and I agree with your vision. We even talked about this on IRC the
other day, remember?
However, I want to focus on getting trunk into a working state that we
can release, with some improvements over 1.7. Something we can get ready
for shipping within the next few months. At the current rate of progress
I don't think targeting the ideal design for 1.8 is a realistic goal by
any measure. Or do you have uncommitted changes sitting on your hard
drive that implement update/merge with Ev2 and a good conflict store with
a really smart conflict resolver that makes use of it? I don't :(
Please be more realistic about what we can achieve for the next release.
Received on 2012-03-16 19:13:15 CET