Modify sys/conf/newvers.sh so that the SVN revision string that is placed (e.g.) in uname output reflects the most recent revision on the branch (for the current working copy), as well as the most recent commit that affected the repository.
Currently, newvers,sh uses svnversion to create a "version identifier" -- which reflects the most recent commit to the repository (as well as an indication that the working copy has been modified with respect to what is currently committed to the repo). Thus, if I have a repo at r339583, then use that repo to check out working copies for stable/11, stable/12, and head/13, then build FreeBSD on each, the salient part of the "uname" string will be " r339583:" (if there are no modifications) or " r339583M" if there are modifications -- for each of those branches.
This can be confusing, as r339583 was a commit only for head/13.
This change would represent the above situation via the strings: "r339580M/339583", "r339549M/339583", and "r339583M/339583" (respectively -- assuming modifications).
By the same token, the current code would represent the SVN revision for stable/11 from working copies updated from a repo at each commit between r339446M - r339530 with each of those 85 distinct revisions; the proposed change would retain those 85 distinct values for the "denominator", while using "r339446M" as the "numerator" in each case.
I am "not fussed" over the actual representation -- this effort was borne out of a bit of frustration when I wanted to examine the last commit on a branch. But I'll try to explain why I made the decisions I did.
I wanted to depict the most recent commit for the branch; I also wanted to retain the possible modification flags. And since we have considerable history using the last commit in the repo, I thought it would be of some use to retain that in some fashion.
The "Last Changed Rev" (to refer to the output of "svn info") seems to match what is wanted for the "most recent commit on the branch"; even better, "svn info" is much faster than "svnversion." Unfortunately, "svn info" does not appear to have a way to provide the modification flags (that "svnversion" does). And while "svnversion" accepts a "-c" flag, which is documented as getting "last changed rather than current revisions", empirically, that output doesn't correspond with "svn info --show-item last-changed-revision" at all.
From my (somewhat naive) perspective, I think of the modification flags as applying to the working copy, not the repo. Thus, I wanted the flags to be on the revision for the working copy, not the revision for the repo.
And I note that the "last revision for the branch" must be no greater than the "last revision for the repo" -- so representing this pair as a "fraction" seemed to make some sense... as long as any applicable "modification flags" were moved from the "last revision for the repo" to the "last revision for the branch". So I kept the use of "svnversion" (as that seems to be the only way to get the modification flags), then used shell substring-processing to (effectively) "move" any flags from the "ast revision for the repo" to the "last revision for the branch".
While I was there, I changed the invocation of svnversion to specify the target working copy as an argument, rather than changing the current working directory to the working copy in question and relying on the implied "current working directory" to determine the working copy to examine.
I have been using a variant of this for several years. (The version I actually use has the VCS-specific code factored out of newvers.sh, leaving newvers.sh to "source" an external file that defines a shell function, which newvers.sh then invokes to obtain the appropriate VCS-specific revision string.)