From owner-freebsd-stable@FreeBSD.ORG Wed Mar 13 05:29:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78EC739E for ; Wed, 13 Mar 2013 05:29:55 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id D3040247 for ; Wed, 13 Mar 2013 05:29:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r2D5Tjg1027841; Wed, 13 Mar 2013 16:29:45 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 13 Mar 2013 16:29:45 +1100 (EST) From: Ian Smith To: John Mehr Subject: Re: svn - but smaller? In-Reply-To: Message-ID: <20130313152150.E32142@sola.nimnet.asn.au> References: <513E2DA5.70200@mac.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1975432105-1363152585=:32142" Cc: Michael Ross , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 05:29:55 -0000 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" wrote: > > On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr 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 then 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--