Date: Fri, 10 Jul 2009 01:32:43 -0700 From: Brian Somers <brian@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Konstantin Belousov <kib@FreeBSD.org>, svn-src-stable-7@FreeBSD.org Subject: Re: svn commit: r195485 - in stable/7/sys: . contrib/pf kern 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <max@love2party.net> 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 > <kib@FreeBSD.org> 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 <brian@Awfulhak.org> Don't _EVER_ lose your sense of humour ! <brian@FreeBSD.org> --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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090710013243.68775e75>