From owner-freebsd-stable@FreeBSD.ORG Thu Mar 14 02:11:35 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 BABB2A82 for ; Thu, 14 Mar 2013 02:11:35 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback3.g2host.com [208.42.184.243]) by mx1.freebsd.org (Postfix) with ESMTP id 6E8232FA for ; Thu, 14 Mar 2013 02:11:34 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback3.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11167462 for freebsd-stable@freebsd.org; Wed, 13 Mar 2013 21:11:28 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Wed, 13 Mar 2013 21:11:28 -0500 Message-ID: In-Reply-To: <20130313152150.E32142@sola.nimnet.asn.au> References: <513E2DA5.70200@mac.com> <20130313152150.E32142@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit 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: Thu, 14 Mar 2013 02:11:35 -0000 On Wed, 13 Mar 2013 16:29:45 +1100 (EST)  Ian Smith wrote: > 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. 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!