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

Re: svn commit: r9485 - in trunk/subversion: libsvn_delta libsvn_fs tests/libsvn_delta

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-28 21:29:11 CEST

Greg Hudson wrote:

>On Wed, 2004-04-28 at 03:56, Branko Čibej wrote:
>
>
>>A consequence of removing the baton and checks from compose_window is
>>that now compose_handler only checks B->src_ops when it sets up the
>>initial baton, but those are never checked later. Which means that if a
>>windoe in the middle of the delta uses no source ops, we'll still do the
>>combination. Given your cnahges in this commit, I think
>>svn_txdelta__compose_windows should check B->src_ops. I'd also change
>>the allocation guarantee slightly, so that compose_windows can return B
>>without having to copy it to the pool (the compose_handler
>>implementation already assumes so, but that't not documented).
>>
>>
>
>Please see http://www.contactor.se/~dast/svn/archive-2004-04/1183.shtml
>if you missed it the first time around.
>
>
Yup, read that; unfortunately didn't have time to respond before.

>I do think that you're correct, and I misread the FS code I was
>modifying. But I think the right fix is more along the lines of:
>
>Index: subversion/libsvn_fs/reps-strings.c
>===================================================================
>--- subversion/libsvn_fs/reps-strings.c (revision 9551)
>+++ subversion/libsvn_fs/reps-strings.c (working copy)
>@@ -189,6 +189,7 @@
> svn_pool_destroy (cb->window_pool);
> cb->window = composite;
> cb->window_pool = composite_pool;
>+ cb->done = (composite->sview_len == 0 || composite->src_ops == 0);
> }
> else if (window)
> {
>
>Does that seem reasonable?
>
>
I personaly prefer functions to be self-contained rather than requiring
their clients to handle preconditions. In this case I have a hard time
finding any other argument, as long as libsvn_fs is the only client of
svn_delta__compose_windows.

Since these are internal interfaces, I can live with this solution. +1.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 28 21:30:53 2004

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.