On 3/8/07, Mark Phippard <markphip@gmail.com> wrote:
> On 3/8/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
>
> > On 3/8/07, Mark Phippard <markphip@gmail.com> wrote:
> >
> > > Why don't we just let someone write this as a Subversion feature and let
> the
> > > committers decide later if they want to push parts of the framework
> upstream
> > > to APR. It would be disappointing if the only way someone could use
> this
> > > feature was if they build Subversion with APR 1.3 or later.
> >
> > Why is it disappointing to require apr 1.3 to get a certain feature?
> > Why is it a problem at all?
> >
> > We already have certain features that require particular versions of
> > BDB. Or neon. Or even serf.
> >
>
> Because you are pushing the problem off on the user.
Well, no, we're pushing off the problem on to the people who package
things. :-)
> We have people that
> want builds for Apache 2.2 today. Now, I realize the issue of us providing
> Windows binaries is a touchy subject, but in the end we do. Are we going to
> provide builds that use the newer APR?
Why not? When BDB 4.4 came out with auto-recovery feature, didn't
Collabnet start producing binaries that used that?
> Then there is the issue of users of
> distros like RHEL which do not provide the latest and greatest versions for
> a long time.
Those same distros aren't going to provide svn 1.5 right away either.
So if some packager wants to create their own svn 1.5 RPM, they can
package an APR 1.3 RPM (and possibly a new apache RPM) to go with it.
Either way, I'm not sure how this issue is relevant. Some distros
release things quickly, some slowly. Packagers for various distros
are used to dealing with this.
> In terms of SOC, we could still let them write this as a Subversion feature
> and let the committers do the work of refactoring this into APR and holding
> it out of trunk until that is completed. I would think if this feature was
> going into APR someone (on the Apache side) would want to open the
> discussion of whether and when httpd would switch to using it. That would
> likely slow down the process of getting it into the official API.
That's a possiblity, yeah. Then again, APR is an independent project.
Not every api it exports is used by Apache. Just because something
goes into APR doesn't mean Apache has to use it.
>
> Is the issue the platform-dependent elements? Coudln't we punt on this?
> Write a logging API and only provide an implementation that logs to files?
> If we log to a file most people can get the rest of what they might want
> pretty easily and we could leave it to APR to eventually provide more
> options.
I honestly don't remember the details, just that when we've had this
design discussion in the past, there seemed to be some consensus about
how a major part of the feature belongs in APR. Maybe we should dig
up those discussions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 8 21:40:03 2007