On 11/28/05, Greg Stein <gstein@lyra.org> wrote:
> On Sun, Nov 27, 2005 at 10:34:42PM -0600, Peter Samuelson wrote:
> >
> > [Justin Erenkrantz]
> > > The RA layer is exactly intended to allow for this type of
> > > flexibility - so I think we'd be working 'against' the RA layer if we
> > > tried to be too cute. By and large, my opinion is the ra name means
> > > very little. I don't think users would really care if we add an
> > > ra_serf as long as it handles http and https.
> >
> > Indeed. You know, in the experimental stages, it wouldn't hurt to
> > register protocols serf:// and serfs:// instead of http:// and
> > https://, and compile both libraries. Later you could grow the
> > configure test, and later still, if libsvn_ra_serf ever matures to the
> > point of being able to replace libsvn_ra_dav unconditionally, it
> > wouldn't be hard at all to delete the one and rename the other.
>
> Interesting thought. It would certainly be a bit handier from a
> testing standpoint to have an svn that is still functional for your
> "normal" work.
>
> Assuming that it will end up being built as ra_serf, does it need to
> go into a branch? We use branches to avoid disrupting developers'
> normal work, but given that an explicit switch to ./configure would be
> needed to see this (and especially if a (debug) scheme were used),
> then it seems it would be easier to keep the dev on trunk. [...]
If the new Serf-friendly protocols are developed on trunk, then they
will be shipped with Subversion 1.4. Will we need to worry about
binary compatibility for a library and protocol that is still in the
early stages of development?
Perhaps we should document explicitly that we do not support backwards
compatibility on a binary- or protocol-level for Subversion binaries
compiled using the new "--enable-serf" option?
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Received on Mon Nov 28 22:10:09 2005