Date: Wed, 13 Mar 2013 09:00:21 +0100 From: Damien Fleuriot <ml@my.gd> To: Ian Smith <smithi@nimnet.asn.au> Cc: Michael Ross <gmx@ross.cx>, John Mehr <jcm@visi.com>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: svn - but smaller? Message-ID: <10533395-DAA0-4AD4-9CA3-89672F28BC71@my.gd> In-Reply-To: <20130313152150.E32142@sola.nimnet.asn.au> References: <web-11636850@mailback4.g2host.com> <513E2DA5.70200@mac.com> <web-12282796@mailback4.g2host.com> <op.wts7cnaeg7njmm@michael-think> <web-11149903@mailback3.g2host.com> <20130313152150.E32142@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Mar 2013, at 06:29, Ian Smith <smithi@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@ross.cx> wrote:
>>> On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr <jcm@visi.com> wrote:
> [..]
>>>> Hello,
>>>>=20
>>>> 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 [...]
>>>=20
>>> What'd you think about a syntax extension along the lines of
>>>=20
>>> svnup --bsd-base
>>> svnup --bsd-ports
>>> svnup --bsd-all
>>>=20
>>> with automagic host selection, default to uname's major version stable
>>> branch and default target dirs?
>>=20
>> Hello,
>>=20
>> This sounds good to me, and as long as there's some sort of a consensus t=
hat
>> we're not breaking the principle of least surprise, I'm all for it. The o=
ne
>> default that may be unexpected is the defaulting to the stable branch --
>> people who track the security branches will be left out. So maybe someth=
ing
>> like:
>>=20
>> svnup --ports
>> svnup --stable
>> svnup --security (or --release)
>>=20
>> Thoughts?
>=20
> Hi John,
>=20
> I have a few ..
>=20
> Firstly, this is a great advance for I suspect many people who aren't=20
> developers as such, but want to simply update sources for some or all of=20=
> the reasons Ike spells out on his wiki page. The sooner this hits the=20
> tree the better in my view, but adding more features won't speed that.
>=20
> I have a small test system on which I'd installed (two instances of) 9.1=20=
> so a couple of days ago I fetched ports with portsnap, installed svnup,=20=
> and ran it using the (just what I needed) example command in svnup(1).
>=20
> I get about 700KB/s here, and svnup took about 15 minutes to update 9.1=20=
> sources to 9-stable. This is fine. Last night I ran it again, but it=20
> took 12:42 to make no changes. This seemed puzzling, as you'd said only=20=
> a few minutes for subsequent updates, but the reason appears to be that=20=
> in both cases, I ran it in script(1), and the default verbosity of 1=20
> includes a listing of every directory and file examined, followed by=20
> <CR> then <erase to eol> codes. Even in less -r (raw) mode it still has=20=
> to display and skip through all the (now invisible) lines; bit messy.
>=20
> Even the second do-nothing run made a 2MB script file, the original with=20=
> all 9.1 to -stable updates being 3.4MB. So I'd love the option to only=20=
> list the changes (- and +) and simply ignore unchanged dirs/files=20
> without any display for use in script(1). Apart from that, I'm happy.
>=20
> As is, it more or less follows csup(1) type arguments, and I think that=20=
> as a c{,v}sup replacement that's appropriate. Making its arguments more=20=
> like svn's may actually be confusing, if it leads people to think of it=20=
> as "svn light" when it really isn't, especially with no .svn directory.
>=20
> As we have portsnap, which updates INDEX-* and checks integrity, I'm not=20=
> sure that using svnup for ports is worthwhile considering. It would=20
> save (here) 135MB in var/db/portsnap, but that's pretty light in view of=20=
> the 700MB-odd of /usr/ports/.svn in the ports distributed with 9.1-R
>=20
I beg to differ, if I can only use the tool to upgrade my base sources but n=
ot the ports, thus still needing vanilla SVN, then I for one won't have any u=
se 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=20=
> think specifying base/stable/9 or whatever is good; it helps people with=20=
> 10 or more years of 9-STABLE or 9.1-RELEASE etc syntax adapt to the svn=20=
> reality but remains explicit enough to put in a script and know just=20
> what's being fetched, without regard to the fetching machine's uname.
>=20
> Not to go as far as emulating supfiles, but a few things (host, branch=20
> and target dir) would be useful in a small .conf file that could be=20
> specified on command line, as a supfile is to csup, perhaps?
>=20
> And svnup(1) really should mention that any files in the target tree not=20=
> in the repository will be deleted, which was (explicitly) not the case=20
> with c{,v}sup. I only lost a few acpi patches that I think have likely=20=
> made it to stable/9 anyway, and it's a test system, but I was surprised.
>=20
> All the best John; as a first contribution I think this is fabulous!
>=20
> cheers, Ian
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10533395-DAA0-4AD4-9CA3-89672F28BC71>