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