This is an old revision of the document!
Description
CVS includes expansion of $FreeBSD$ to revision number of the file's most recent change on checkout. This makes it possible to:
- Easily see which revision a source file is at
- Easily see whether a source file is affected by a security issue (“Revisions of foo.c after 1.12 do not have this problem”)
- Easily see which revisions of source files a binary is built from
The alternative VCS does not need to support $FreeBSD$ directly. However, it must provide a mechanism to allow developers and end users to carry out those three tasks.
The use of $FreeBSD$, rather than the more common $Id$ (in CVS) is so that if we import files from other projects that use $Id$, we don't end up clobbering their version number with the version number in our repo.
Current Implementation
SVN Implementation
Hg Implementation
Hg by default does no keyword expansion at all. There are practical reasons not to do this (including the fact that it does complicates the job of the VCS) but it is seen as FreeBSD developers as a useful feature. Therefore, someone has written an Hg extension to do expansion of certain keywords.
This allow for the hash of the changeset that touched a file last to be inserted in the file like $Id$.
Like git, hg does have some commands to give information about files and revisions: hg tip gives you the revision your repository is at, hg log gives you the entire history of the repository or files you are looking at.
Git Implementation
This could be done within whatever CVS importer tool is used for existing CVS revisions, as that tool is writing out the blobs and has access to the CVS revision numbers at the same time. This isn't done in parsecvs yet, but would be easy. However, this revision numbering wouldn't be maintained for new commits to git (since it's distributed, and there's no way to make sensical monotonically-increasing version numbers in a distributed system).
For discussing revisions in debugging, git show shows what sha1 is at the top of your current branch, git-rev-list shows what sha1s are in the history of your branch, and comparing the position a user's latest sha1 with the sha1 of a fix you did in the git-rev-list tells you if a user has a given fix in their tree.