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. Rather than do that, you're
saying it's worth delaying the interim release so we can fix the
badness the Right Way.
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?
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?
-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 09:28:45 2002