Re: svn commit: rev 1080 - trunk/subversion/include trunk/subversion/libsvn_fs trunk/subversion/mod_dav_svn trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta trunk/subversion/libsvn_ra_dav

On Sun, Jan 27, 2002 at 08:08:25PM -0500, Greg Hudson wrote:
> On Sun, 2002-01-27 at 19:32, gstein@tigris.org wrote:
> > Turn svn_txdelta_window_t into a readonly structure, rather than a
> > dual purpose build/use structure.
>
> I don't particularly agree with this change, on two grounds:
>
> 1. The motivation for it isn't very clearly spelled out. Is there a
> real problem with having a dual-purpose build/use structure in this
> case?

Yup. The svn_stringbuf_t usage poses problems. In many cases, we aren't
actually accumulating data, but simply referring to some existing data (this
is generally seen in the cases where we are copying content thru the delta
interface; refer to svn_txstream_send_string, fetch_file_read, etc).

A similar issue, but less so, for the ops member.

I'm getting rid of svn_stringbuf_t everywhere we use it for non-accumulating
purposes (i.e. just passing data around). The stringbuf pose particular
problems for language bindings. When an svn_stringbuf_t is called for, the
binding code must come up with a pool from somewhere (bindings/ruby/,
bindings/java/jni/, and bindings/swig/ all see this problem).

The only piece of code that accumulates data into window.new_data is the
code in text_delta.c (and implicitly vdelta.c). So I moved all of the
building code into a baton.

> 2. Assuming there is a good motivation for the change, I don't see any
> reason to use a baton (which has no type safety) for building
> instructions. Why not define a real, fixed type for the instruction
> buffer?

Good point. I can change this to make it typesafe, especially since it is
all internal. Patch coming up...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org