Karl Fogel wrote:
>Branko Čibej <brane@xbc.nu> writes:
>
>
>>That's sort of inherent in how Philip's patch works. It turns out Mike
>>was right -- it's caused by the way
>>libsvn_client/repos_diff.c:add_directory calls the notification
>>function. The only way to fix that is to teach svn_wc_add to DTRT
>>during a merge, which we all agree is non-trivial.
>>
>>So, while this patch introduces a new feedback bug, it does fix the
>>fundemental brokenness of merge, which is that it doesn't preserve
>>copy history.
>>
>>
>
>Ah.
>
>So in other words: a largely good change caused one bad side effect
>(it broke the notification output). To fix that small badness
>quickly, we'd have to undo the good work.
>
Yes.
> Rather than do that, you're
>saying it's worth delaying the interim release so we can fix the
>badness the Right Way.
>
I'm saying we need the good work in the interim release, and can live
with the bad side effect in that release because it's essentially an
aesthetic issue, not a semantic one. I'm absolutely _not_ saying we
should delay the interim release. That's why I moved issue 838 back to
Beta again.
>I haven't inspected the code to understand what "we all agree is
>non-trivial", right now I'm only going by other people's posts about
>it. But:
>
>If it's truly non-trivial to get this notification problem fixed while
>leaving the new code in place, then it seems to me that work that
>probably should have been done on a branch was done on the trunk
>instead. I mean, the main reason we've used branches so far is to
>avoid breaking trunk, right?
>
It's so hard to answer the same questions in two threads ... but yes, I
agree further development should be on a branch. It's not just about
getting the feedback right (BTW, the feedback problems are descrbed in
my latest comments to issue 838), it's also about using svn_wc_add with
history correctly instead of using svn_client_copy, as we're doing now.
The add-with-history is easy for files, but non-trivial for directories,
I think -- Philip can correct me if I'm wrong.
>I'm all for fixing this directly in trunk if that can be done quickly
>-- but if it can't be done quickly, then we should be prepared to take
>those changes out of trunk, and work on them in a branch until they're
>ready. (And if we do that, it's perfectly okay for a new tarball to
>go out with "svn merge" still as broken as it was in the previous
>tarball. There will be plenty of other improvements in this interim
>release.)
>
>Do you find any of this controversial?
>
>
No, not controversial. It's just that I feel very strongly that the
merge semantics should be fixed ASAP, and that the incidental --
temporary and "issueized" -- weirdness in the feedback is a low enough
price to pay for that.
In the end, it boils down to this: do you think I should revert
revisions 2910 and 2911? They don't break the tests, and the feedback
problem shows up _only_ during merge, nowhere else.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 22:16:52 2002