Page MenuHomeFreeBSD

Teach how to get the last revision on the branch

Authored by dhw on Oct 22 2018, 9:42 PM.
Referenced Files
Unknown Object (File)
Tue, Apr 9, 2:01 AM
Unknown Object (File)
Mon, Apr 8, 12:17 PM
Unknown Object (File)
Feb 21 2024, 10:58 AM
Unknown Object (File)
Feb 19 2024, 6:01 AM
Unknown Object (File)
Jan 31 2024, 3:58 PM
Unknown Object (File)
Jan 2 2024, 8:04 PM
Unknown Object (File)
Dec 22 2023, 10:45 PM
Unknown Object (File)
Dec 13 2023, 5:28 AM



Modify sys/conf/ 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, leaving to "source" an external file that defines a shell function, which then invokes to obtain the appropriate VCS-specific revision string.)

Diff Detail

Lint Skipped
Tests Skipped

Event Timeline

I've updated the diff a bit in response to some suggestions -- thanks for those!

(The changed lines are the same: I merely applied the diff to a full checkout, then used 'svn diff -x -U999999 > /tmp/D17653.diff' to regenerate it.)

A real-world example: the "uname -a" strings from my home "build machine" as of this morning:
s1.0:FreeBSD 11.2-STABLE FreeBSD 11.2-STABLE #847 r340058M/340097: Sat Nov 3 04:02:51 PDT 2018 amd64

vs. my desktop at work [I'll redact the hostname]:
FreeBSD work_desktop 11.2-STABLE FreeBSD 11.2-STABLE #12 r340058M/340114: Sun Nov 4 03:45:59 PST 2018 root@work_desktop:/common/S1/obj/common/S1/src/sys/GENERIC amd64

Note that it's trivial to see that they were actually built from the sources at the same revision (r340058), while the "stock" would have shown them as r340097M and r340114M (respectively) -- which (in each case) really is r340058 on the stable/11 branch, but it takes a bit of work (and reference to external information) to see that. I prefer making things easier for people.

Oh, nice. I immediately got flamed for mentioning that version discrepancy on the FreeBSD forums (with closed as a consequence), so this patch is extremely welcome.

kevans added a subscriber: emaste.

Tagging @emaste as well, but I think this looks good to me as-is.

I think this is a good idea, but haven't looked at it in detail yet

Thanks. This is not urgent -- I've been kinda sitting on it for years. And please consider this a proof of concept to illustrate the nature of the problem and a possible solution: I am not hung up on any part of the implementation.

Overcome by Events

I think this is still useful, is there any concern of committing this to head?

I certainly have no objection to someone using the idea(s) and committing code based on what's here. That said, this has been sitting here since October 2018.

I think this is still useful, is there any concern of committing this to head?

Indeed, sorry that this slipped off my list. I agree that this is a good idea and hopefully lwhsu or I will take a look soon.


Is there any reason we shouldn't use just svn_l, not svn_l/svn?

My opinion? Implementor's "artistic license" call. :-)

I kept the old value (last commit to repo) around in part so I could see where there was a difference (and thus, that this change had value); in part because that way, that part of it was consistent with prior practice. Besides, I ended up getting it already (as a side effect of fetching the modification flag); once that's done, displaying it is trivial.

I'm not hung up on it either way.