Re: svn error during 'make buildkernel'?

On Thu, Aug 08, 2013 at 11:14:05AM -0400, John Baldwin wrote:
> On Tuesday, August 06, 2013 2:30:54 pm Glen Barber wrote:
> > On Tue, Aug 06, 2013 at 01:11:07PM -0500, Matthew D. Fuller wrote:
> > > On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of
> > > Glen Barber, and lo! it spake thus:
> > > > 
> > > > The error generated is non-fatal, and once I receive response on a
> > > > proposed patch, will be suppressed if the svn version used to check
> > > > out the tree is not compatible with that used to check the version
> > > > of the tree with the kernel build.
> > > 
> > > But not try the ports svn as well?  I mean, as breakage goes, it's not
> > > even in the top 100; I'd _much_ rather have a kernel that I have to
> > > guess the revision of but boots, than one properly recorded that
> > > doesn't.  But it's still unpleasant, and is one of those things you
> > > probably won't notice missing until suddenly you need it.
> > > 
> > > And this isn't just a presentism.  Sure, right _now_ devel/subversion
> > > and base svnlite get along, but what happens when ports moves to 1.9
> > > which changes the WT format?  Even if -CURRENT src gets upgraded
> > > simultaneously[0], the same surely can't be said of every back branch.
> > > 
> > > I realize this is all still a WIP, and please don't read any anger
> > > into my words.  But this _has_ been something I've found a little
> > > worrisome since the original import/newvers change.  Heck, newvers can
> > > show me version info if I'm getting my source tree from git or p4, but
> > > can't handle ports svn?  By the time this works its way into a stable
> > > branch, I really think it should either handle svnversion from ports
> > > as well, or come with a big bright flashing warning that using svn
> > > from anything but base svnlite for /usr/src is a degraded experience.
> > > 
> > > 
> > > [0] Which still wouldn't really fix things, since
> > >     /usr/bin/svnliteversion is arbitrarily old, not up to date with
> > >     the source tree.
> > > 
> > 
> > I have this on my todo list, but right now I have bigger things to deal
> > with.  As soon as I can, I will fix the logic.  Right now, it is not "as
> > easy as checking which svn works", because the more I look at the logic
> > for newvers.sh, the more I dislike how it all works.
> 
> BTW, I was totally surprised by this recent error on my laptop which still
> has 1.7 installed.  I don't rebuild ports all the time because it's a PITA.
> I think the fact that svnliteversion is used in preference to svnversion
> is a huge POLA violation and completely agree with Steve on this one.
> It shouldn't be that hard to just check $? and fallback to svnliteversion
> if svnversion fails.  I have much more complex hacks in place at work where
> we have active 1.6, 1.7, and 1.8 clients. :(
> 

Fixed in r254094.

Glen