On Wed, 13 Mar 2013 16:29:45 +1100 (EST)
Ian Smith <smi...@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" <g...@ross.cx> wrote:
> > On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr
<j...@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!
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
