From owner-cvs-src@FreeBSD.ORG Wed Jan 9 06:31:51 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69DBD16A41B for ; Wed, 9 Jan 2008 06:31:51 +0000 (UTC) (envelope-from peter@wemm.org) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id C63C713C468 for ; Wed, 9 Jan 2008 06:31:50 +0000 (UTC) (envelope-from peter@wemm.org) Received: by fg-out-1718.google.com with SMTP id 16so134861fgg.35 for ; Tue, 08 Jan 2008 22:31:49 -0800 (PST) Received: by 10.82.158.12 with SMTP id g12mr462350bue.18.1199860309425; Tue, 08 Jan 2008 22:31:49 -0800 (PST) Received: by 10.82.182.2 with HTTP; Tue, 8 Jan 2008 22:31:49 -0800 (PST) Message-ID: Date: Tue, 8 Jan 2008 22:31:49 -0800 From: "Peter Wemm" To: "Max Laier" In-Reply-To: <200801082039.18671.max@love2party.net> MIME-Version: 1.0 References: <200801081908.m08J8wIs094059@repoman.freebsd.org> <200801082039.18671.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, "David E. O'Brien" Subject: Re: cvs commit: src/sys/netinet6 frag6.c icmp6.c in6.c in6_ifattach.c in6_pcb.c in6_proto.c in6_rmx.c in6_src.c ip6_input.c ip6_mroute.c ip6_output.c mld6.c nd6.c nd6_nbr.c nd6_rtr.c raw_ip6.c udp6_usrreq.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 06:31:51 -0000 On Jan 8, 2008 11:39 AM, Max Laier wrote: > On Tuesday 08 January 2008, David E. O'Brien wrote: > > obrien 2008-01-08 19:08:58 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/netinet6 frag6.c icmp6.c in6.c in6_ifattach.c > > in6_pcb.c in6_proto.c in6_rmx.c in6_src.c > > ip6_input.c ip6_mroute.c ip6_output.c > > mld6.c nd6.c nd6_nbr.c nd6_rtr.c > > raw_ip6.c udp6_usrreq.c > > Log: > > un-__P() > > Do we do that again w/o immediate need and other changes to that file? I > was under the impression that it is deemed repo churn. That aside, I'm > all for the change. > Once apon a time (before cvsup) we used CTM - CVS-through-email - as the only way to get the cvs repository. The previous state of the tree was stored and a series of diffs were generated relative to the last run. The more that was touched, the larger the email update. When I first started developing on freebsd, that was how I got it. CTM chunks over a UUCP link. Other folks with real internet connections (ppp or maybe even a 64K link.. perhaps even a (gasp!) T1 link at the unimaginable speed of 1.5mbit/sec - they used this thing called 'SUP'. If you changed one character in a file, it downloaded the entire file from scratch. Those were the days that the 'avoid needless changes' policy was really critical. Roto-tilling the tree was painful for people downstream. Now, we have cvsup, anoncvs and rsync. It is a night-and-day difference. For the most part, we can afford cosmetic fixes and cleanups. There are people still getting CTM deltas, but it isn't as bad as SUP (which died the death it deserved). The main remaining constraints are concessions to the limitations of our SCM system and politeness to other developers. We need to avoid trivial changes for: 1) code that involves branches due to the suckiness of cvs, and 2) merge conflicts cause everybody pain. It is no fun getting 100 conflicts because somebody just did a de-__P() sweep. Having said that, we have grown overly sensitive to both 1) and 2). 1) will be fixed soon enough, and 2) is mostly a big deal only on stuff that other people are actively developing on. I'm not sure that we have too much activity in the ipv6 stack, and it certainly isn't vendor code anymore (the vendor has gone away). Now doing a roto-till of something like __P() in the ipv4 stack wouldn't be such a hot idea because there are lots of projects in progress that are already stomping on each other's toes. There isn't much room for gratuitous changes in there. However, ipv6 previously missed the tree-wide de-__P() sweep because (at the time) it was vendor code. For what its worth, I'm glad it was cleaned up. Also, I think we've gone too far in avoiding changes to vendor branched code "at all costs". It isn't *that* broken. I like what NetBSD(?) does these days by using the new -X flag(?) to cvs import, which takes the files off the vendor branch INSTANTLY. This is a very good thing as it gets the pain out of the way and fills a few huge holes in the vendor branch metadata. PS: and a pox on anybody who uses this as an excuse to revive the VCS bikeshed. If you do, I will forward a copy of every single email message that has been said on the subject since 1995. Individually. -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5