Phillip Martin writes:
> Tom's example was contrived to give a conflict, I can
> contrive one that does not
It's not clear to me that that's relevent. We can't any of us come up
with a perfect scheme, so what we must settle for is an optimal one,
which:
(1) Does the right thing as much as possible.
(2) Clearly signals the other cases, so a human can resolve the matter.
(3) Really, really minimize the cases where it thinks it got it right,
but is in fact wrong.
I claim that (1) is the ultimate goal, but perversely enough (2) is more
important than (1), and (3) is the most important of all.
That there are non-conflicting instances is good, of course, we want as
many of them as possible, but the real measure of the system is (3): not
lying.
I agree with Tom, that conflicting changes (in this hard-to-detect
sense) will arise, and need to be taken into account. I won't quibble
with Philip over whether they represent process flaws, I will only point
out that this tool exists, in part, to identify and protect us from our
errors, while getting as much as possible right to save us time.
The classic strategy for dealing with these conflicts is "region
widening" -- not only the elsewhere-quoted widening of the context, but
also widening of the delta region itself. This often "works" only in
that it produces an uglier merge failure, satisfying (2). If variance
adjusting really turns an ugly delta into an unsignaled lie, that would
be a major offense; this is, I think, a restatement of Tom's concern.
My question would be, "how often do these conflicting fixes in the same
area arise?" If often, we should worry; if rarely, perhaps not. I have
a lot of experience in a situation where this sort of thing was in fact
the norm, representing well over 50% of a change rate of several
thousand deltas a day. While I recognize this was an extreme case, I
have to say it makes me very chary of stepping into this mess. But this
is exactly and solely the question that has divided "change-based"
advocates from "version-based" advocates for fifty years; I dare suggest
we won't actually resolve it on this list, either.
What I do suggest is that the variance adjusting might be tweakable, to
reduce its exposure here. A possibility: use a word-list culled from
the various regions, to see if any of the variances being "based" refer
to words also in the putative delta region; if so, then decide that
these variances are too risky for the tool to autodecide: widen the
delta region and try again.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 10 02:34:35 2003