Request for comments - svnup in base ?
Ian Smith
smithi at nimnet.asn.au
Thu Jan 22 14:26:05 UTC 2015
In freebsd-questions Digest, Vol 555, Issue 1, Message: 10
On Sun, 18 Jan 2015 12:16:31 -0600 Andrew Berg <aberg010 at my.hennepintech.edu> wrote:
> On 2015.01.18 11:45, Ian Smith wrote:
> > svnlite only arrived with 10.1, so is not what 8.x and 9.x users need.
> 10.0, not 10.1. I am a bit surprised that it wasn't backported to 9.3, though.
Hmm, well if that's so, man.cgi hss it wrong; it only shows up when
selecting 10.1 or 10-stable, not 10.0. But then, I've found a few odd
things in man.cgi the last couple of months so I'm not confident I can
trust it re what versions support various things lately - like this one?
One example; enter 'pkg' with default settings, you get pkg(7) which of
course has links to pkg(8) - clicking on which meet 'not found' unless
you select <some version> AND PORTS. For another, try looking for 'ep';
you get nothing unless you know in advance that you have to pick 'i386';
I think the 'default' architecture (presumably amd64?) should say 'ANY'.
svn(1) is available as a port for 9.3, but not svnlite(1) .. and I think
neither deserve their (1) until there's a real 'how to use it' manual.
> > So just how 'lite' is svnlite? Could someone running 10.1+ please
> > replace svnup with svnlite in equivalents to the following queries:
> >
> > smithi at x200:~ % ll `which svnup`
> > -r-xr-xr-x 1 root wheel 47040 Jan 19 01:26 /usr/local/bin/svnup
> [candace ~]# ls -l $(which svnlite)
> -r-xr-xr-x 1 root wheel 3210464 Jan 3 22:26 /usr/bin/svnlite
Yeah, under 1.5% :)
> > smithi at x200:~ % ldd `which svnup`
> > /usr/local/bin/svnup:
> > libmd.so.5 => /lib/libmd.so.5 (0x800824000)
> > libssl.so.6 => /usr/lib/libssl.so.6 (0x800a34000)
> > libc.so.7 => /lib/libc.so.7 (0x800c8a000)
> > libcrypto.so.6 => /lib/libcrypto.so.6 (0x800fe5000)
> [candace ~]# ldd $(which svnlite)
> /usr/bin/svnlite:
> libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x800b29000)
> libz.so.6 => /lib/libz.so.6 (0x800d50000)
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800f66000)
> libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801186000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x8013a4000)
> libssl.so.7 => /usr/lib/libssl.so.7 (0x801798000)
> libthr.so.3 => /lib/libthr.so.3 (0x801a03000)
> libc.so.7 => /lib/libc.so.7 (0x801c28000)
In both cases, pretty standard libraries.
> > smithi at x200:~ % ll /lib/libmd.so.5 /usr/lib/libssl.so.6 /lib/libc.so.7 /lib/libcrypto.so.6
> > -r--r--r-- 1 root wheel 1407536 Jun 25 2014 /lib/libc.so.7
> > -r--r--r-- 1 root wheel 1748528 Jun 25 2014 /lib/libcrypto.so.6
> > -r--r--r-- 1 root wheel 69072 Jun 25 2014 /lib/libmd.so.5
> > -r--r--r-- 1 root wheel 355576 Jun 25 2014 /usr/lib/libssl.so.6
> [candace ~]# ls -l /lib/libbsdxml.so.4 /lib/libz.so.6 /lib/libcrypt.so.5
> /usr/lib/libmagic.so.4 /lib/libcrypto.so.7 /usr/lib/libssl.so.7
> /lib/libthr.so.3 /lib/libc.so.7
> -r--r--r-- 1 root wheel 161760 Jan 3 22:25 /lib/libbsdxml.so.4
> -r--r--r-- 1 root wheel 1647720 Jan 3 22:25 /lib/libc.so.7
> -r--r--r-- 1 root wheel 62008 Jan 3 22:25 /lib/libcrypt.so.5
> -r--r--r-- 1 root wheel 2038496 Jan 3 22:26 /lib/libcrypto.so.7
> -r--r--r-- 1 root wheel 106120 Jan 3 22:25 /lib/libthr.so.3
> -r--r--r-- 1 root wheel 89576 Jan 3 22:25 /lib/libz.so.6
> -r--r--r-- 1 root wheel 123976 Jan 3 22:25 /usr/lib/libmagic.so.4
> -r--r--r-- 1 root wheel 439776 Jan 3 22:26 /usr/lib/libssl.so.7
My, how things have grown between 9.3 and 10.1. But that's not so much
extra, I guess working out the size of svnlite's installed dependencies
would be more revealing. I haven't a 10.x system to check, and I'm not
assuming it carries most of svn's load, but svnup(1) has none at all.
> > smithi at x200:~ % du -hd0 /usr/src
> > 830M /usr/src
> > smithi at x200:~ % du -hd0 /usr/ports
> > 1.6G /usr/ports
Sorry, ports was completely bogus; including over 500MB of distfiles ..
> [candace ~]# du -hd0 /usr/src
> 783M /usr/src
Similar; I've got a few patches and diffs in there.
> and FWIW:
> [candace ~]# du -sh /usr/src/.svn
> 398M /usr/src/.svn
You mean your /usr/src without .svn/ would only be 385M? That seems
small, unless it's compressed? Also, perhaps .svn/ is compressed now?
I was saying 'almost double' from the /usr/ports/.svn that accompanied
the ports distribution with 9.2-R.
> This is a two-week-old checkout of 10-STABLE (from which the aforementioned
> binaries were built).
> I don't have a ports tree from SVN (both trees I use for poudriere are using
> portsnap at the moment).
I've never had an issue with portsnap, though we see some say they have.
I wouldn't recommend using svnup for ports either, but haven't tried it.
> I'm not sure any of the above matters too much, but I might do a speed
> comparison of svn, svnup, and svnlite, which I think will be the most important
> for most people if they are indeed that much different from each other in that
> regard.
If you do, be sure to compare an initial fetch of a tree to small (or
no change) updates. svnup used to be kinda slow on initially fetching
and building a tree, and quite fast enough, for me, for incrementals.
Also check svn vs http vs https methods. I need to do more tests too.
Again, svnup is specifically for non-developer, more casual updaters.
> On a side note, backticks are bad and you shouldn't use them. :P
Because?
> > Bottom line: I don't think plugging to get svnup into base is worth
> > pursuing. Few developers took any interest that I noticed, it was
> > largely tested by users. John Mehr has been very responsive to any
> > issues. To one to whom C is mostly read-only, it reads very well.
> >
> > I think it's ok as a port .. perhaps a small section in the Handbook?
> A mention in the handbook would definitely be good.
Yeah; I wish I wan't so crap at documentation, too verbose by half ..
now if we could convince Warren to check it out .. :)
Polytropon's point about documentation stands. svn is deep and wide;
there are primers and wiki pages for those getting their teeth into it,
but its manpage could at least point to something immediately useful.
Polytropon wrote:
> Good documentation is an essential point, no matter if
> you see it as a developer or as a user. Both "man cvs"
> and "man csup" fulfill that requirement.
As does do svnup(1) and svnup.conf(5). Pretty painless to check out;
you can point it elsewhere than /usr/src to play around and compare.
cheers, Ian
More information about the freebsd-questions
mailing list