Page MenuHomeFreeBSD

newvers: append commit count to uname version string
AcceptedPublic

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

Details

Reviewers
imp
cem
Summary

In a git-only world this provides a facsimile of a monotonically increasing version number.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

emaste created this revision.May 29 2019, 1:49 PM
emaste added a subscriber: julian.May 29 2019, 1:57 PM

In a fork based on our svn2git mirror (i.e., based on https://github.com/freebsd/freebsd 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).

cem accepted this revision.May 29 2019, 5:32 PM

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.

E.g.

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
emaste added a subscriber: kmoore.May 30 2019, 1:58 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.