svn - but smaller?

John Mehr jcm at
Thu Mar 14 02:11:35 UTC 2013

On Wed, 13 Mar 2013 16:29:45 +1100 (EST)
 Ian Smith <smithi at> wrote:
> 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 
> without any display for use in script(1).  Apart from 
>that, I'm happy.

Which mirror are you using?  I ran several tests tonight 
repeatedly fetching 9/stable from (so they 
would all be do-nothing runs) both inside and outside of a 
script(1) capture and on both an old SSD and on a ZFS 
mirrored array (to see if the target media made any 
difference) and they all completed in 2 minutes, 43 
seconds +/- 2 seconds on my 350 KB/s connection.

I'll definitely put in a verbosity level that does exactly 
what you suggest.  Sorry about that.

> 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.

This is an excellent point, and I agree 100%.

> 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, 

Actually, after reading both this message and Alexander 
Yerenkow's excellent suggestion, I think implementing some 
sort of supfile/.conf/aliases file (with command line 
parameters overriding the settings in the 
supfile/.conf/aliases) is the way to go.

> 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.

I always thought csup did delete files.  I was looking at 
csup's man page for things to put on the to-do list and 
there's a csup command line parameter ( -d ) that puts a 
limit on the number of files that can be deleted in a 
given run.  Adding this feature is already on my to-do 
list, and I've just added another item to let the user 
choose whether svnup should delete extra files in the 
local source tree.

> All the best John; as a first contribution I think this 
>is fabulous!
> cheers, Ian

Thank you for the kind words and the constructive 
feedback.  It's very much appreciated!

More information about the freebsd-stable mailing list