• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Infrastructure → Build environment
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ajb - 2009-01-04
Last edited by Unhelpful - 2009-01-19

FS#9758 - Make svnversion agnostic to version control mechanism

The current attempt to deal with git repos fails if it’s not a svn-repo (which is won’t be if people have synced of the rockbox git repo). This patch makes the version script agnostic about git-svn and use Linux style id if git is detected.

Closed by  Unhelpful
2009-01-19 16:53
Reason for closing:  Accepted
Additional comments about closing:  

committed as r19799

I like your detection of “dirty” status of the repository, but I believe we should still report the latest SVN revision in the git repository as part of the version string. This can be done without git-svn by examining the log of the current branch, since git-svn commits are marked as such.

ajb commented on 2009-01-05 12:24

But how do you determine which log entry? After all most developers
using git will have their own commits on top. Ultimately the reported
version is most useful to the person that built that build. The git
commit ID marks exactly where and what revision history a given change
has. They can easily refer to a subversion revision if reporting
anything to Flyspray manually.

I dealt with it by searching for the most recent commit, via git log, with a git-svn-id. There’s no reason the SVN revision could not be included with the git commit ID, although at that point it might be getting too long to read on the screen… you’re probably right, though, in that only developers are using git, and if they build test builds from it for users, it’s enough that the developer knows what to do with the git commit ID.

ajb commented on 2009-01-11 14:19


Removed extraneous tag checking code (hangover from Linux kernel)
Detected git-svn-id in HEAD commit message and will echo “grNNNNN” if in sync with SVN

ajb commented on 2009-01-12 12:23

Following Andrews comment:

“it’s probably going to need to report the most recent git-svn commit regardless of whether it’s HEAD or not. people want it to always show where the build fits in the svn repo, and at least some are against even appending a git commit ID.”

I’ve changed the logic so a pure git commit will report and ID like: gd53f268(~r19748)-090112 which means git commit-ish d53f268 which is rooted from r19748

ajb commented on 2009-01-12 16:34


Fixed -dirty handling

Several devs on IRC seems to agree about keeping the version string short, simple, and in the same format across targets. This is a modified patch that outputs rNNNNN[M]-DDDDDD version strings for git repositories, with the optional “M” appearing if the commit at HEAD is not from svn, or if the working tree contains changes to existing files, or any other changes (file add/delete/rename) that have been staged for commit with git add. I can commit this now, if the mechanism is considered generally acceptable, and leave the task open to work on adding more complete info to rockbox-info.txt - this file is already included in builds, and could have “Git commit ID” and “Git working tree status” fields added.

The major objections to extending the version string itself are that differences based on version control systems may confuse users, and that the existing version string already barely fits the screen on some targets, and actually goes over by a few pixels with the “M” for modified. Such targets would end up seeing nothing in the bootloader display with a -<commitID> added to the version string, and if we have to ask users to look at the version via the menu to get the commit ID, they may as well look at rockbox-info.txt.

ajb commented on 2009-01-19 15:53

As Andrews patch but with commentary fixed.


Available keyboard shortcuts


Task Details

Task Editing