From owner-svn-src-stable@FreeBSD.ORG Fri Jul 10 09:01:55 2009 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BBF3106566C; Fri, 10 Jul 2009 09:01:55 +0000 (UTC) (envelope-from prvs=1435d1a1eb=brian@FreeBSD.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id AAE3F8FC19; Fri, 10 Jul 2009 09:01:54 +0000 (UTC) (envelope-from prvs=1435d1a1eb=brian@FreeBSD.org) Received: from pd2ml2so-ssvc.prod.shaw.ca ([10.0.141.134]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 10 Jul 2009 02:33:02 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=0wvbOQHW_X4A:10 a=4Z0QP1WVBuUwHZGQKe2N1A==:17 a=27BTIGBgAAAA:8 a=6I5d2MoRAAAA:8 a=MMwg4So0AAAA:8 a=WalxI9PLPnwHhWfnXLQA:9 a=PgzLLtScnHhelxcWAe0A:7 a=sSXPXt5biKByYQFK8xRSD45BiAEA:4 a=L4ceHOG9r0gA:10 a=SV7veod9ZcQA:10 a=WJ3hkfHDukgA:10 a=clesq3LJ7767UxsK2kcA:9 a=v52IL87XUYfgkvc_3eNa3bLN4bUA:4 Received: from unknown (HELO store.lan.Awfulhak.org) ([174.7.23.140]) by pd2ml2so-dmz.prod.shaw.ca with ESMTP; 10 Jul 2009 02:33:02 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A928FC433AD_A56FCF9B; Fri, 10 Jul 2009 08:34:01 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 67821C460F2_A56FCEEF; Fri, 10 Jul 2009 08:33:50 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n6A8WnkU055951; Fri, 10 Jul 2009 01:32:50 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Fri, 10 Jul 2009 01:32:43 -0700 From: Brian Somers To: Max Laier Message-ID: <20090710013243.68775e75@dev.lan.Awfulhak.org> In-Reply-To: <200907092235.18828.max@love2party.net> References: <200907090912.n699CGx0077581@svn.freebsd.org> <20090709103126.02bf7206@Awfulhak.org> <200907092235.18828.max@love2party.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rFctUl0UDsGXPXkb74725ab"; protocol="application/pgp-signature" Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Konstantin Belousov , svn-src-stable-7@FreeBSD.org Subject: Re: svn commit: r195485 - in stable/7/sys: . contrib/pf kern X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 09:01:55 -0000 --Sig_/rFctUl0UDsGXPXkb74725ab Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 9 Jul 2009 22:35:18 +0200 Max Laier wrote: > On Thursday 09 July 2009 19:31:26 Brian Somers wrote: > > On Thu, 9 Jul 2009 09:12:16 +0000 (UTC), Konstantin Belousov=20 > wrote: > > > Author: kib > > > Date: Thu Jul 9 09:12:16 2009 > > > New Revision: 195485 > > > URL: http://svn.freebsd.org/changeset/base/195485 > > > > > > Log: > > > MFC r194993: > > > In lf_iteratelocks_vnode, increment state->ls_threads around iterat= ing > > > of the vnode advisory lock list. This prevents deallocation of state > > > while inside the loop. > > > > > > Modified: > > > stable/7/sys/ (props changed) > > > stable/7/sys/contrib/pf/ (props changed) > > > stable/7/sys/kern/kern_lockf.c > > > > Just picking on this commit.... > > > > Are the properties on stable/7/sys/contrib/pf intentional or should > > they merged into stable/7/sys (a no-op hopefully) and removed? >=20 > No it shouldn't[*]. The problem is that contrib/pf is - as the path sugg= ests=20 > - backed by contributed code and thus has vendor specific merge info. >=20 > [*] That being said, I don't really care about the merge info in there - = as it=20 > turns out, subversion's automerging capabilities are rather poor anyway a= nd I=20 > can't see the benefit of the mergeinfo in dealing with vendor code. It's= =20 > always easy enough to figure out the revisions you want merged and you do= n't=20 > really need the mergeinfo for that. OTOH, it is valuable meta-informatio= n=20 > that should be recorded - as I recall that's one reason why we switched t= o=20 > subversion in the first place. >=20 > One way out - which I proposed several times before but never got feedbac= k on=20 > - would be to change the hierarchies in vendor-sys to have an extra=20 > sys/contrib prefix (e.g. vendor-sys/pf/dist/*sys/contrib*/pf/...). This = way=20 > we can record the mergeinfo in src/sys as well and get rid of the extra i= nfo=20 > in contrib/* I'd need some feedback from svn-savvy people to go this roa= d,=20 > though. >=20 > Before somebody asks why pf is the only offender - simply because it's th= e=20 > only sys/contrib source with a post-cvs merge of vendor code to the relen= g. Yes, I was thinking along the same lines. AFAICT this would work fine with the caveat that it may be necessary to import some vendor code in pieces. If for example a vendor distributed some-package/etc/config-file some-package/bin/program some-package/kernel/driver we might need to import it in two pieces so that we can maintain the contrib/some-package part of the hierarchy when merging sys/, even though the other two hierarchies can be merged directly into src/etc and usr.bin/program directly. However, the bit that I don't understand about the original commit and its update of the contrib/pf mergeinfo is why it's updated at all by svn - it just seems wrong. When I do: cd svn/stable/7/sys svn merge -c NNNNN ^/head/sys given that change NNNNN has nothing to do with pf, I don't understand why subversion updates stable/7/sys/contrib/pf's mergeinfo. Is the "special" thing about sys/contrib/pf just that it already has mergeinfo associated with it? And if so, why does that make it special. Surely having NNNNN in sys's mergeinfo implies that it's been merged to every part beneath sys. Having said all that, svn's --depth switch allows partially sparse tree checkouts, and it's always possible to svn revert part of a merge before committing. This implies that the only way svn could successfully maintain mergeinfo would be to store it at least against every node with a merged modification. Depending on how people branch and merge, this would become very unwieldy very quickly (certainly in other environments if not in ours (we would get away with it because we eventually forget about old branches)). So I guess I'm probably just re-iterating other people's suggestions that svn's merge capabilities are somewhat dysfunctional by design. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! --Sig_/rFctUl0UDsGXPXkb74725ab Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQCVAwUBSlb8sQ7tvOdmanQhAQKWEgP+IurTl/qMrTDE6WZmhfpdOiDuWOHxcr9l r7FUI0PS8sxinwlGBunkaDyQSZbx4UDojhZQuAw/mnuzOZjitEmEs1ERlDSMCCOB ihH0JQKvVZxYjXp4LF+cAL2H8qVNoXG79hnaHGH9Cykrv3jfegGK7qonktSixUCV cUNJxz+S7Js= =UxkA -----END PGP SIGNATURE----- --Sig_/rFctUl0UDsGXPXkb74725ab--