svn commit: r195485 - in stable/7/sys: . contrib/pf kern

Brian Somers brian at FreeBSD.org
Fri Jul 10 09:01:55 UTC 2009


On Thu, 9 Jul 2009 22:35:18 +0200 Max Laier <max at 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 
> <kib at 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 iterating
> > >   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?
> 
> No it shouldn't[*].  The problem is that contrib/pf is - as the path suggests 
> - backed by contributed code and thus has vendor specific merge info.
> 
> [*] That being said, I don't really care about the merge info in there - as it 
> turns out, subversion's automerging capabilities are rather poor anyway and I 
> can't see the benefit of the mergeinfo in dealing with vendor code.  It's 
> always easy enough to figure out the revisions you want merged and you don't 
> really need the mergeinfo for that.  OTOH, it is valuable meta-information 
> that should be recorded - as I recall that's one reason why we switched to 
> subversion in the first place.
> 
> One way out - which I proposed several times before but never got feedback on 
> - would be to change the hierarchies in vendor-sys to have an extra 
> sys/contrib prefix (e.g. vendor-sys/pf/dist/*sys/contrib*/pf/...).  This way 
> we can record the mergeinfo in src/sys as well and get rid of the extra info 
> in contrib/*  I'd need some feedback from svn-savvy people to go this road, 
> though.
> 
> Before somebody asks why pf is the only offender - simply because it's the 
> only sys/contrib source with a post-cvs merge of vendor code to the releng.

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.

-- 
Brian Somers                                          <brian at Awfulhak.org>
Don't _EVER_ lose your sense of humour !               <brian at FreeBSD.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-stable/attachments/20090710/b49a9fbf/signature.pgp


More information about the svn-src-stable mailing list