Date: Sun, 23 Jun 2013 11:12:53 -0600 From: Warner Losh <imp@bsdimp.com> To: Tijl Coosemans <tijl@FreeBSD.org> Cc: src-committers@FreeBSD.org, Andre Oppermann <andre@FreeBSD.org>, Peter Wemm <peter@wemm.org>, John Baldwin <jhb@FreeBSD.org>, svn-src-all@FreeBSD.org, David Chisnall <theraven@FreeBSD.org>, Garance A Drosehn <gad@FreeBSD.org>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... Message-ID: <3E89DDCB-38FA-4E7C-8F03-461516DD1871@bsdimp.com> In-Reply-To: <51C6E89A.6060407@FreeBSD.org> References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <A5DB9B17-9622-4F65-A902-4984CDD82DC3@FreeBSD.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <F96228E4-16C3-4238-B54B-7E7C0C08B95B@FreeBSD.org> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> <51C6E89A.6060407@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 23, 2013, at 6:22 AM, Tijl Coosemans wrote: > On 2013-06-23 04:43, Garance A Drosehn wrote: >> On 6/22/13 2:38 PM, Tijl Coosemans wrote: >>> On 2013-06-20 21:34, Warner Losh wrote: >>>>=20 >>>> I think insisting on a definitive statement on svn lite's mission >>>> statement is a way to obstruct progress. Sometimes you just need to >>>> things because they feel right, not because they have been through = a >>>> 20-step approval process... >>>=20 >>> For what it's worth, my reservations have always been because it >>> didn't feel right. I never asked for an approval process. >>>=20 >>> I do think there should be a tool in base that can fetch source >>> updates and it would be nice if it could roll back changes and >>> even nicer if it could do bisects. But svn itself is not the >>> right tool for that. >>>=20 >>> For instance, will you allow that svn is updated from version x.y >>> to x.(y+1) in a stable branch? If yes, then users might have to run >>> run "svn upgrade" which is a one way process, so how does importing >>> svn allow you to roll back changes or do bisects then? If no, then >>> who's volunteering to backport security fixes? >>=20 >> What was added to the base system was 'svnlite', not 'svn' from >> the official subversion project. The distinction is that >> 'svnlite' is a version meant only for access to the official >> FreeBSD repositories. 'svnlite' in the base system would only >> be upgraded when it is needed to match the FreeBSD respository. >> And if you need to run 'svn upgrade' to access the FreeBSD >> repository, then it doesn't make much difference if you have >> to do that with 'svnlite' or via the official 'svn' port. >>=20 >> I'm not sure that my comments provide an answer to what you're >> concerned about, but anyone who wants the latest version of >> 'svn' to match their own repositories is still going to need >> to install the port. We're not going to blindly update >> 'svnlite' every time a new version of 'svn' is released. >> 'svnlite' is going to be updated on *FreeBSD*'s schedule, >> not on the schedule of the subversion project. >>=20 >> It is true that we're going to have to be careful when it does >> come time to switch to some new repo-format for the FreeBSD >> repository. We might find ourselves in some kind of chicken- >> and-egg situation at that point. And when we do make a >> significant upgrade to the FreeBSD repository, then we're >> going to have to upgrade 'svnlite' across multiple FreeBSD >> branches at the same time, including all -stable branches. >> But when that issue comes up it'll come up on our schedule, >> because we'll control both 'svnlite' and the FreeBSD repo. >=20 > It is precisely the other way around. Once you do a FreeBSD release > (releng branch) that release will be stuck with the same version of > svnlite for years. You will end up with multiple releases with > multiple versions of svnlite that you cannot change. You have zero > control. Then they will never have to do svn update, since their checked out tree = will never be obsolete in relationship to the version that's installed. > A port on the other hand is the same for all branches and releases > of FreeBSD. It is a single point where you have total control over > the version of svn for all users. Conceptually, a port corresponds > to the fact all branches and releases share the same subversion > repo. Except that you still need to do svn update on trees that are checked = out from old repos. I'm having a real hard time seeing this as an issue based on my = experience with the svn port since we made the switch. Then again, I've = been talking to the svn repo over http, which is independent of the = version of the repo on the other end... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E89DDCB-38FA-4E7C-8F03-461516DD1871>