svn - but smaller?

Ian Smith smithi at
Wed Mar 13 05:29:55 UTC 2013

On Tue, 12 Mar 2013 18:32:28 -0500, John Mehr wrote:
 > On Tue, 12 Mar 2013 02:20:37 +0100
 >  "Michael Ross" <gmx at> wrote:
 > > On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr <jcm at> wrote:
 > > > Hello,
 > > > 
 > > > I'm currently in the process of adding http/https support to svnup and
 > > > once I've got that working, the command line interface will be changing
 > > > to be more like the traditional svn client to make it easier for people
 > > > to adopt the tool [...]
 > > 
 > > What'd you think about a syntax extension along the lines of
 > > 
 > > 	svnup --bsd-base
 > > 	svnup --bsd-ports
 > > 	svnup --bsd-all
 > > 
 > > with automagic host selection, default to uname's major version stable
 > > branch and default target dirs?
 > Hello,
 > This sounds good to me, and as long as there's some sort of a consensus that
 > we're not breaking the principle of least surprise, I'm all for it.  The one
 > default that may be unexpected is the defaulting to the stable branch --
 > people who track the security branches will be left out.  So maybe something
 > like:
 > svnup --ports
 > svnup --stable
 > svnup --security (or --release)
 > Thoughts?

Hi John,

I have a few ..

Firstly, this is a great advance for I suspect many people who aren't 
developers as such, but want to simply update sources for some or all of 
the reasons Ike spells out on his wiki page.  The sooner this hits the 
tree the better in my view, but adding more features won't speed that.

I have a small test system on which I'd installed (two instances of) 9.1 
so a couple of days ago I fetched ports with portsnap, installed svnup, 
and ran it using the (just what I needed) example command in svnup(1).

I get about 700KB/s here, and svnup took about 15 minutes to update 9.1 
sources to 9-stable.  This is fine.  Last night I ran it again, but it 
took 12:42 to make no changes.  This seemed puzzling, as you'd said only 
a few minutes for subsequent updates, but the reason appears to be that 
in both cases, I ran it in script(1), and the default verbosity of 1 
includes a listing of every directory and file examined, followed by 
<CR> then <erase to eol> codes.  Even in less -r (raw) mode it still has 
to display and skip through all the (now invisible) lines; bit messy.

Even the second do-nothing run made a 2MB script file, the original with 
all 9.1 to -stable updates being 3.4MB.  So I'd love the option to only 
list the changes (- and +) and simply ignore unchanged dirs/files 
without any display for use in script(1).  Apart from that, I'm happy.

As is, it more or less follows csup(1) type arguments, and I think that 
as a c{,v}sup replacement that's appropriate.  Making its arguments more 
like svn's may actually be confusing, if it leads people to think of it 
as "svn light" when it really isn't, especially with no .svn directory.

As we have portsnap, which updates INDEX-* and checks integrity, I'm not 
sure that using svnup for ports is worthwhile considering.  It would 
save (here) 135MB in var/db/portsnap, but that's pretty light in view of 
the 700MB-odd of /usr/ports/.svn in the ports distributed with 9.1-R

As for stable, release or security branches (of which major release?) I 
think specifying base/stable/9 or whatever is good; it helps people with 
10 or more years of 9-STABLE or 9.1-RELEASE etc syntax adapt to the svn 
reality but remains explicit enough to put in a script and know just 
what's being fetched, without regard to the fetching machine's uname.

Not to go as far as emulating supfiles, but a few things (host, branch 
and target dir) would be useful in a small .conf file that could be 
specified on command line, as a supfile is to csup, perhaps?

And svnup(1) really should mention that any files in the target tree not 
in the repository will be deleted, which was (explicitly) not the case 
with c{,v}sup.  I only lost a few acpi patches that I think have likely 
made it to stable/9 anyway, and it's a test system, but I was surprised.

All the best John; as a first contribution I think this is fabulous!

cheers, Ian

More information about the freebsd-stable mailing list