Re: Speeding up the 'svn commit' process?

On Thu, Jul 11, 2002 at 04:08:45PM -0400, Greg Hudson wrote:
> On Wed, 2002-07-10 at 09:09, Kevin Pilch-Bisson wrote:
> > I disagree. Rather, I think we should export the baton carrying functions, as
> > well as two functions to create/finish with batons. Then the consumer of the
> > API determines the life of the baton. This makes sense, since they are the
> > only ones who know how long the operation is going to last.
>
> Uh, if I understand what you're proposing, this is not really a baton as
> we understand it.
>
> First, it shouldn't be a void *. There's only one wc library, and thus
> only one structure type needed to hold cached data. If you want to use
> forward structure declarations to make it opaque to the caller, great,
> but don't make it a void *. No need to sacrifice type safety
> unnecessarily.

You (and Karl and Philip, and everyone else) are right. There isn't (aren't?)
going to be more than one type of working copy cache, so it shouldn't be void
*. I do think it should be opaque. However, as that change has already been
comitted, the point is moot.
>
> Second, as Ben said in a separate thread, when most of us see "baton" we
> think "user data"--that is, something opaque to the callee but
> transparent to the caller. (The editor interface may be an exception,
> but once you're in vtable-land things are already kind of convoluted.)
> What we have here is more of a "context"--something opaque to the caller
> but transparent to the callee.
>
Ah yes, it was the editor interface thing that was confusing me. I'll second
context as a good term for this type of structure.

And, I'll try to be more precise about what I'm saying in the future. :)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~