Okay, I'm sorting out some of the issue #838 stuff now.
Here is a summary of the situation:
We had a bug whereby "svn merge", when merging added files into the
working copy, did not preserve their copyfrom history. This is
broken. We all agree that the right fix is to libsvn_wc, to make
it handle copyfrom arguments, and then to use it from merge. But
that's a big job, so the quick workaround fix is to just use
svn_client_copy() whenever merge encounters a copied item. This
fixes the bug, but it's horribly inefficient, since it refetches
data that has already been fetched once before. It also introduces
a bug in the feedback, such that the printed output of "svn merge"
is now incorrect -- but, as it happens, our test suite had a bug
that didn't catch this particular brokenness, so the test suite
still passes. Nice, eh?
So we had a merge semantics bug (copyfrom history not preserved),
which we traded for a feedback bug. The total number of bugs present
in head has not changed :-).
I've fixed the test suite so that it detects the notification bug now.
I'm running full "make check" to see if it uncovers any *more* bugs,
besides the expected feedback bogosity stimulated by Branko's new test
merge_test.py:add_with_history. Then I will try to fix Subversion, so
that merging with history gives correct feedback too -- in other
words, reducing the total number of bugs in head :-).
Brane, and possibly others, suggest that this fix may not be possible
within the current framework, and that it may require first doing the
Right Fix (i.e., the "big job" referred to above) to merge.
I think they may be right. If investigation confirms this, it would
be better for us to revert revision 2910 (the workaround), and move
its development to a branch, until it fixes the original problem
*without* introducing any new problems. So that's my plan.
Why, you may ask, am I proposing to live with a semantic bug in order
to avoid a mere feedback bug?
Because the semantic bug is known and being worked on, but doesn't
hurt anyone except that they don't get as much copy history as they
might want. Whereas the feedback bug -- also known -- is very
user-visible, and thus will cause posts to the list and possible
duplicate issues filed. And every single one of these will be a waste
of time for both submitter and receivers, because all aspects of the
bug are already known.
If we already know about a subtle bug, there's no point trading it for
an unsubtle bug, just so we can include the unsubtle one in an interim
release :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 21:05:27 2002