21–29 of 29 posts
It is very useful if the same code compiles to the same binary if no changes occurred.
But having the date and time or a version control comment change a binary may lead to unnecessary churn with dependencies, packages, and integrity checks.
I work on a code base dating back to 2000. First years, the change log was kept at the top of the file, in a comment. Commit comments were automatically inserted into the file by a "$Log" directive (CVS). The first 200 lines are just 20 year old commit log entries, none of them providing any valuable information ("minor changes", "changed XYZ to be consistent with spec", "reenable reporting"). So much cargo culting.
I work on a code base dating back to 2000. First years, the change log was kept at the top of the file, in a comment. Commit comments were automatically inserted into the file by a "$Log" directive (CVS). The first 200 lines are just 20 year old commit log entries, none of them providing any valuable information ("minor changes", "changed XYZ to be consistent with spec", "reenable reporting"). So much cargo culting.
I work on a code base dating back to 2000. First years, the change log was kept at the top of the file, in a comment. Commit comments were automatically inserted into the file by a "$Log" directive (CVS). The first 200 lines are just 20 year old commit log entries, none of them providing any valuable information ("minor changes", "changed XYZ to be consistent with spec", "reenable reporting"). So much cargo culting.
A lot of these techniques are fragile, and complicate lots of other things. It is very useful if the same code compiles to the same binary if no changes occurred. But having the date and time or a version control comment change a binary may lead to unnecessary churn with dependencies, packages, and integrity checks.
FreeBSD finally removed the last of the $Id$ in the source some months ago. I don't entirely know why they were so keen to do this but I'm sure they had a reason. I don't see this, or binary .ident strings as e.g. clashing with idempotent builds.
FreeBSD finally removed the last of the $Id$ in the source some months ago. I don't entirely know why they were so keen to do this but I'm sure they had a reason. I don't see this, or binary .ident strings as e.g. clashing with idempotent builds.
FreeBSD finally removed the last of the $Id$ in the source some months ago. I don't entirely know why they were so keen to do this but I'm sure they had a reason. I don't see this, or binary .ident strings as e.g. clashing with idempotent builds.
Does anyone have information about these lines? Are they auto-generated?
They were very useful when you were looking at a source file, to see what version of that file you had.
Git had something similar with Git Attributes[3], but AFAIK, they were just references to blob ids, so they never really took off.
For git, I now use tags (and versioning based on tags), that more or less replaced svn/cvs keyword substitution in the git ecosystem.
[1] - https://svnbook.red-bean.com/en/1.7/svn.advanced.props.speci...
[2] - https://www.gnu.org/software/trans-coord/manual/cvs/html_nod...
[3] - https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...