Tom Lord <lord@emf.net> writes:
> Consider, for example, a common ancestor that starts with:
>
> T:8 == B:1
> ----------
>
> last = x;
> val = 2 * x;
> foo (val);
>
> On the trunk:
>
> T:20 (second line changed from T:19)
> ----
>
> last = x;
> val = 2 * (counter += x);
> foo (val);
>
> And on the branch:
>
> B:15 (first line changed from B:1)
> ----
>
> last = x, counter += x;
> val = 2 * x;
> foo (val);
>
> In this case, both the trunk and branch programmers added a needed
> increment of `counter', but they did it in different ways, on nearby
> but different lines.
Fixing the same bug in two different ways is a mistake, it should be
fixed in one place and merged to the other. Yes, mistakes will
sometimes happen, but at other times adjacent changes like those above
will not be a conflict.
[...]
> which will apply without conflict to B:15, yielding:
>
> B:16
> ----
>
> last = x, counter += x;
> val = 2 * (counter += x);
> foo (val);
>
> which (because of the duplicated assignments to counter) is likely to
> be the wrong result.
I disagree, this is not the wrong result--from a version control point
of view the changes have been combined perfectly.
> Now, to be fair -- even regular textual patching, without the variance
> algorithm, can introduce surprising bugs. Patching is inherently
> dangerous that way.
>
> But one of the ways we traditionally reduce that risk is by using
> context diffs -- and variance adjusted patching appears to be a
> mechanism precisely designed to undo the benefits of that safety
> measure.
Context diffs could be viewed as a safety measure, but they can also
be viewed as way of allowing a patch to be applied to a modified
source. Personally I value the latter more than the former.
> The example above illustrates a case where ordinary patching would do
> the right thing, generate a conflict and help a programmer to notice
> the bug, but variance adjusted patching will silently hide the bug.
Whether it is a bug depends on the interpretation of the code, and
that is beyond the scope of version control. There will be cases
where adjacent changes should behave exactly as you show above.
> A less aggressive form of variance adjustment would seem to me to be
> safer: and that would be just to adjust the line offsets of hunks (not
> their contents) in response to out-range additions and deletions.
> That would defeat the window-size limitation of the patching tool
I've not yet examined the Subversion merge code, but I know that when
I wrote some merge code in the past I did it without context at all, I
just did line adjustment as you describe above. I was pleased with
the results it produced, I considered your "wrong result" above to be
a positive advantage.
It's not as if merge affects the repository, the user gets to compare
the sources of the merge before merging, and also gets to view the
result of the merge before committing.
[...]
> Yet even _that_ kind of adjustment presents new dangers, and I don't
> think I'd want it to be the default.
It boils down to the question: how often should adjacent,
non-overlapping changes result in a conflict? I prefer the answer
"never", you appear to prefer "always". I don't suppose either of us
can prove which is the most likely to be correct in the real world.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 9 01:26:15 2003