From owner-freebsd-current@FreeBSD.ORG Fri May 8 20:16:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C16A665A; Fri, 8 May 2015 20:16:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AAF31BB0; Fri, 8 May 2015 20:16:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9786CB94E; Fri, 8 May 2015 16:16:51 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: NGie Cooper , Pedro Giffuni , Lyndon Nerenberg Subject: Re: What to do about RCS/OpenRCS Date: Fri, 08 May 2015 11:44:44 -0400 Message-ID: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 08 May 2015 16:16:51 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 20:16:52 -0000 On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote: > On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni wrote: > > Hello; > > > > On 05/07/15 14:56, Lyndon Nerenberg wrote: > >> > >> On Thu, 7 May 2015, Pedro Giffuni wrote: > >> > >>> Unfortunately I don't use RCS enough (it looks like I should though) so > >>> I am not in a good position to take the next step and deal with any > >>> fallout it may produce. > >> > >> > >> If we can have a build-knob to disable GNU RCS and enable the new one I > >> will happily twist up the new version and hammer on it. > >> > > > > Yes, that's usually the next step in the process. It is a little bit messy > > because > > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and > > perhaps something else that we don't use). > > > > I really want to check out first if there is some strong opinion against > > OpenRCS. Perhaps someone that has used it before and thinks it is a > > bad idea. > > > > It looks like there are voices against it, so those have to be addressed > > first. > > Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs > bits); check with jhb first to make sure that OpenRCS works with > etcupdate. > Cheers! I think this can be fixed by using diff3 instead of merge, I just haven't sat down and figured out the correct incantation. That said, I think that having a not-quite-working rcs (OpenRCS) in base is worse than having no rcs. If OpenRCS is improved as per Xin's notes then just switching over is probably the path of least resistance. I guess I see the following options: 1) Just leave GNU RCS in the tree. 2) Improve OpenRCS so it can be swapped in. 3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate) and import just a /bin/ident binary (perhaps from OpenRCS). Both 2) and 3) require some work. I suspect 3) requires less. :) -- John Baldwin