Page MenuHomeFreeBSD

newvers: append commit count to uname version string

Authored by emaste on May 29 2019, 1:49 PM.

Diff Detail

rS FreeBSD src repository - subversion
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

In a fork based on our svn2git mirror (i.e., based on master branch) this will produce a version number like: r348309+937a4a817304-c260384(wipbsd.20190326)-dirty. We'd generate e.g. r348309=937a4a817304-c360384(test) in a git svn-based fork.

In a git-only world (without modifications in the tree) we'd get something like 156c41aa9bed-c260203(master).

If there is a cheap way to do it, it might be nice to stop counting at the first (latest) SVN revision. That way git starts over with lower "revision" numbers once an actual switch is made. It's also a shorter walk through git's object graph.


git_lastsvn=$($git_cmd log -1 --notes --grep 'svn path=.*; revision=[0-9]*' | awk '{ print $2; exit }')
git_cnt=$($git_cmd rev-list --count ${git_lastsvn}..HEAD)

Which shows something more like "c27" for me (matches the depth of my git patch stack not present in SVN). Unlike your numbers, these numbers will float until we actually turn off SVN, so there's a tradeoff there. Since I'm not the target audience for this feature, maybe someone who likes revision numbers should share their preferences.

Functionally, I don't see anything wrong with the change.

This revision is now accepted and ready to land.May 29 2019, 5:32 PM

Note that Git can internally store a generation count (tree height) and if that's a suitable proxy for us that can be instantaneous to calculate, however within a given branch a given generation count does not necessarily identify a unique commit.

Since any way we choose to represent this today is non-canonical I'll go with this and we can reconsider later when we start producing prototype/test releases from git.