On 13 Mar 2013, at 06:29, 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. > > 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 >
I beg to differ, if I can only use the tool to upgrade my base sources but not the ports, thus still needing vanilla SVN, then I for one won't have any use for said tool whatsoever. Just my take on it. I'm totally not into portsnap. > 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 > _______________________________________________ > 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" _______________________________________________ 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"