I have been tracking FreeBSD stable (head - 1; sometimes head - 2) & head for some years. Despite the occasional issue, for the most part this actually works without much trouble. A while after the switch to SVN (and the appearance of the SVN revision in the uname output), the thought occurred to me that it might be useful for me to maintain a record of revisions that worked for me. A bit more recently, I actually decided to do it.
(See the above "tracking FreeBSD" link for details on the process, including the csh aliases used.)
The above-cited page ("tracking FreeBSD") mentions
that near the end of a successful smoke-test, I append the output of
uname -vp to a file on several of the machines I
update. I then copy that file (along with a few others) here so
folks can use a Web browser to see pretty much at a glance what
worked for me.
src/sys/conf/newvers.sh so that
the SVN revision returned by uname is -- in my opinion
-- more useful. While this is largely "overcome by events" now that
the FreeBSD project is using git as the Source of Truth, I will leave
this description here as an aid to understanding the historical "uname
-a" outputs from when SVN was used.
The stock version of newvers.sh places the output of
svnversion (if it's available) in the uname
output. Please see the output of svnversion --help for
the details of this output.
For our present purposes, the critical issue for me was that
the cited revision number reflects the revision number of the
most recent commit to the repository as of the point that the
working copy (/usr/src, in this case) as of the time
newvers.sh was run. It is not unusual for the commit
thus referenced to actually be for a branch other than the one used
for the working copy we're using.
A bit of experimentation showed me that svn info:
svnversion does.
svnversion is (probably because of the
immediately-preceding point).
svn info provides a great deal more information than we want:
initially, I piped its output
through awk to filter it down to what I wanted; with more
recent version of SVN, I now simply request the bits I need. But I also thought
that there was value to the "Modified" flag from svnversion -- but that if
I'm going to show the last revision that applied to the branch for the working copy, the
"Modified" flag should be used to modify that (rather than the last revision for
the repository, as svnversion does).
svn_v=$( svnversion /usr/src )
flag="${svn_v##*[0-9]}"
repo_rev=$( svn info --show-item revision /usr/src | sed -e 's/ //g' )
wc_rev=$( svn info --show-item last-changed-revision /usr/src | sed -e 's/ //g' )
echo " r${wc_rev}${flag}/${repo_rev}"
For example, the output of that as I type this is: r251021M/251024.
This may be interpreted to mean that:
/usr/src prior to the
above code running) was r251024.
/usr/src was r251021.
/usr/src -- as it turns out,
the change is the one to newvers.sh that I'm discussing now.
A bit later, I was hacking a port (that created a kernel module) so it would behave properly for
both stable and head; the usual approach is to make use of the OSVERSION
make variable. It turns out that the stock newvers.sh already has this, as
the shell variable RELDATE. So I decided to augment the above (r251021M/251024)
with that information, the result being (in this case): r251021M/251024:901504.
More recently, I decided that since the OSVERSION
is readily available via the uname -K.sh
flag, I should not be placing it in the (default) version string.
So I un-did that last bit.