From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 17:03:56 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6FF42798; Sun, 23 Jun 2013 17:03:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id D33351626; Sun, 23 Jun 2013 17:03:54 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so1867506wiv.9 for ; Sun, 23 Jun 2013 10:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X6hKLr2RApL4PD5QTfOPUzCajYgu5MjDiOE6f5z37uM=; b=bDUyugYLkSoMbB2vgFoe1euZEUpfIZ7aPkUKInFrpU3MGx/6KrfLhwx8+O/63dmvno XBNZxZJng4RcMC/psu6heXmnkGQsW7IlGTi4DHAa3hdOQEs0s2BoKJEXFmLx/T05QDSm irUUNUxlmT0txuOhsuwLMyfssTc0uP7yliCnkq1sxJ+kReP3bjY9WfXKPbzTHmXDJrOp d6hjQaHQt43qkTf0BSIil9cqrGoJs3bJS74u13SRtIyam/CeIFQwHECmiHyKvRw2+Ld9 6/yCbmmJ73uHw7lcL09lpSjfHJ+CQoeohrYn6YWAlDD7i75MOcsL8QCte+eOwmnzQLHw nRCw== MIME-Version: 1.0 X-Received: by 10.180.92.226 with SMTP id cp2mr3975076wib.9.1372007033918; Sun, 23 Jun 2013 10:03:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.202 with HTTP; Sun, 23 Jun 2013 10:03:53 -0700 (PDT) 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> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> <51C6E89A.6060407@FreeBSD.org> Date: Sun, 23 Jun 2013 10:03:53 -0700 X-Google-Sender-Auth: MwyFSun-YfPrZIcUrXcIWhj2zbw Message-ID: 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... From: Adrian Chadd To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 23 Jun 2013 17:40:27 +0000 Cc: src-committers@freebsd.org, Andre Oppermann , John Baldwin , Peter Wemm , svn-src-all@freebsd.org, David Chisnall , Garance A Drosehn , svn-src-head@freebsd.org, Warner Losh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 17:03:56 -0000 You know that there _are_ users that want behaviour (A), and some that want behaviour (B), right? Not everyone wants to run the latest and greatest ports tree on all releases. Adrian On 23 June 2013 05:22, 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: >>>> >>>> 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... >>> >>> For what it's worth, my reservations have always been because it >>> didn't feel right. I never asked for an approval process. >>> >>> 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. >>> >>> 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? >> >> 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. >> >> 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. >> >> 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. > > 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. > > 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. >