svn commit: r350550 - head/share/mk

[John Baldwin]

On 8/7/19 3:19 PM, tech-lists wrote:
> On Wed, Aug 07, 2019 at 02:08:14PM -0700, Xin LI wrote:
> 
> Hi,
> 
>> I haven't dig deep on this topic, but it seems that parsing 'svn info'
>> output would solve it (by using "Last Changed Rev:" value).
>>
>> This issue do not exist on git.
> 
> svn info will not return the revision of the running system. This is my
> point. With reproductible build turned on, there is no way as far as I'm aware
> of getting the revision of the sources the system was built from, and
> that bit of info can be very useful diagnosing/fixing and updating.
> 
> It will return the revision of what the source directory was last updated to.
> That will probably be later than the running system. It won't return
> anything at all of course if the sources are no longer there.
> 
> I'll try explaining another way. Let's say I'm relatively new to freebsd
> and I read up on downloading a 12-stable-snapshot and follow stable.
> Some issue with the base system happens. I email to stable@ and they ask
> what I'm running. I say, (because reproductible build defaults to "on" in
> this example) 12-stable. It's not really helpful to those wanting to
> assist. What benefit is had by losing this information by default?

That is not affected by the reproducible knob.  Builds always include the
output of svnversion.  For example, my desktop machine on stable that has
the default (reproducible on) has:

% uname -a
FreeBSD desktop 12.0-STABLE FreeBSD 12.0-STABLE r347074 GENERIC  amd64

As long as you can do 'svn up -r<XXXX>' to get the same tree that uname -a
claims, svnversion is doing its job, even if the last N commits are
userland-only and don't impact the kernel.

-- 
John Baldwin