svn commit: r222048 - stable/8/sys/fs/nfs

[John Baldwin]

On Thursday, May 19, 2011 5:04:47 pm Doug Barton wrote:
> On 5/19/2011 11:55 AM, Peter Jeremy wrote:
> > On 2011-May-18 02:14:26 +0000, Rick Macklem<rmacklem at FreeBSD.org>  wrote:
> >> Author: rmacklem
> >> Date: Wed May 18 02:14:26 2011
> >> New Revision: 222048
> >> URL: http://svn.freebsd.org/changeset/base/222048
> >>
> >> Log:
> >>   MFC: r221462
> >>   Add a comment noting that the NFS code assumes that the
> >>   values of error numbers in sys/errno.h will be the same
> >>   as the ones specified by the NFS RFCs and that the code
> >>   needs to be fixed if error numbers are changed in sys/errno.h.
> >>
> >> Modified:
> >>   stable/8/sys/fs/nfs/nfsproto.h
> >> Directory Properties:
> >>   stable/8/sys/   (props changed)
> >>   stable/8/sys/amd64/include/xen/   (props changed)
> >>   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
> >>   stable/8/sys/contrib/dev/acpica/   (props changed)
> >>   stable/8/sys/contrib/pf/   (props changed)
> >
> > Picking a commit at random, I notice that lots of -stable commits
> > include property changes to apparently unrelated parts of the tree.
> > Is this intentional?  ViewVC doesn't seem to let me view the actual
> > properties.
> 
> This happens because people do merges at improper locations in the tree, 
> then when people come along and do it right (as Rick seems to have done 
> here) svn helpfully updates the mergeinfo on files/directories that have 
> it below where it is supposed to be.
> 
> Some of us periodically go through and fix this, but it would be very 
> helpful if people would stop breaking it. :)

No, these are all legitimate (or mostly so).  The opensolaris, acpica, and pf 
nodes all have mergeinfo due to merges from the vendor area.

amd64/include/xen is possibly dubious.  If we are never going to do a future 
merge from i386/include/xen to amd64/include/xen then we can just remove that 
mergeinfo.

-- 
John Baldwin