Page MenuHomeFreeBSD

newvers: append commit count to uname version string
ClosedPublic

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

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

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.

This revision was automatically updated to reflect the committed changes.