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. I think the
one decision point *against* using trunk would be if people want to
see the work [on a branch], and evaluate it before allowing it to
trunk. And that sort of falls back to, "does anyone think this is a
bad idea/approach and shouldn't be done?"
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
Received on Mon Nov 28 12:29:17 2005