svn - but smaller?

[Damien Fleuriot]

On 13 Mar 2013, at 06:29, Ian Smith <smithi at 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" <gmx at ross.cx> wrote:
>>> On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr <jcm at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"