Date: Wed, 13 Mar 2013 21:11:28 -0500 From: "John Mehr" <jcm@visi.com> To: <freebsd-stable@freebsd.org> Subject: Re: svn - but smaller? Message-ID: <web-11167474@mailback3.g2host.com> In-Reply-To: <20130313152150.E32142@sola.nimnet.asn.au> References: <web-11636850@mailback4.g2host.com> <513E2DA5.70200@mac.com> <web-12282796@mailback4.g2host.com> <op.wts7cnaeg7njmm@michael-think> <web-11149903@mailback3.g2host.com> <20130313152150.E32142@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Mar 2013 16:29:45 +1100 (EST)
Ian Smith <smithi@nimnet.asn.au> 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@ross.cx> wrote:
> > > On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr
><jcm@visi.com> 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.
Which mirror are you using? I ran several tests tonight
repeatedly fetching 9/stable from svn0.us-west (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,
>perhaps?
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?web-11167474>