Date: Wed, 13 Mar 2013 16:29:45 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: John Mehr <jcm@visi.com> Cc: Michael Ross <gmx@ross.cx>, freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130313152150.E32142@sola.nimnet.asn.au> In-Reply-To: <web-11149903@mailback3.g2host.com> References: <web-11636850@mailback4.g2host.com> <513E2DA5.70200@mac.com> <web-12282796@mailback4.g2host.com> <op.wts7cnaeg7njmm@michael-think> <web-11149903@mailback3.g2host.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1975432105-1363152585=:32142
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
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.
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
--0-1975432105-1363152585=:32142--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130313152150.E32142>