[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Issue 838 merge should copy-with-history

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-08-08 22:16:17 CEST

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.
>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'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
>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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.