svn commit: r222048 - stable/8/sys/fs/nfs
jhb at freebsd.org
Thu May 19 21:30:04 UTC 2011
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
More information about the svn-src-stable-8