svn - but smaller?
Andrew Reilly
areilly at bigpond.net.au
Sat Jan 26 06:17:10 UTC 2013
On Thu, Jan 24, 2013 at 10:45:53AM +0000, Ben Morrow wrote:
> At 9AM +0000 on 24/01/13 you (Ben Morrow) wrote:
> > Quoth 'Jeremy Chadwick' <jdc at koitsu.org>:
> > >
> > > Regarding your "svn-lite" theory of having that added to src/contrib/,
> > > let me introduce you to Subversion's actual dependencies, and I'll
> > > explain why these would have to remain enabled (for a "base system"
> > > Subversion) as well:
> <snip>
> > > * APR (used for HTTP fetching (not necessarily HTTPS))
> > > -- License: http://www.apache.org/licenses/LICENSE-2.0.html
> > > -- Not in the base system
> > >
> > > * Expat 2.x (XML parsing/generation library
> > > -- License: http://en.wikipedia.org/wiki/MIT_License
> > > -- Not in the base system
>
> Correction: expat is in base already, as libbsdxml (rather confusingly
> built under lib/libexpat).
>
> So AFAICS the only remaining piece is APR (and svn itself), and I
> suspect that if only the bits required for a svn client were brought in
> (assuming the licence is deemed acceptable) that would be a lot smaller
> than a full APR build. (Again, this would need to be built as libbsdapr
> to avoid conflicts with real APR from ports.)
If APR is only used for HTTP fetching, I wonder how hard it
would be to replace those pieces with fetch(3), which is in
base, or wrap fetch(3) in an APR-compatability shim? (Some
work required, obviously.) No, I'm not volunteering: svn from
ports works OK for me, and I'm in the process of investigating
freebsd-update+portsnap to keep the source trees up to date...
Took me a while to notice that freebsd-update can be told to
*not* update executables and what-not, but I haven't tried it
myself. Call me a massochist, but I like that my FreeBSD system
is running code built from the source that's there... Part of
FreeBSD's charm, in my opinion.
Cheers,
--
Andrew
More information about the freebsd-stable
mailing list