I do the opposite. Coders check in code, but the build system manages both the version id files and the labeling, so they are always in sync. (we are not using fossil as our vcs at work)
My steps are: Check out code Increment versionids in .h or .java files Build (verify using human eyeballs and quick tests) Checkin work products and .h/.java id files Label sources and work products and .h/.java id files. This process should work for any vcs, whereas yours only works for fossil. Joe -----Original Message----- From: fossil-users [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Jan Danielsson Sent: Wednesday, August 03, 2016 11:24 AM To: Fossil SCM user's discussion Subject: [fossil-users] tags manifest Hello, Since I've finally got a few days off, I've done some updates to the jan-manifest-tags; merge with trunk, made some bugfixes, and thought I'd reintroduce the branch (since it's been a while). The basic idea is the following: It's common practice for projects to tag new release versions of their software. Separately from that, there's a version number somewhere in the source tree (like #define VER_MAJ 1, #define VER_MIN 2, etc). This means that the same information is available in two different places and Someone(tm) needs to make sure they match. The idea for a tags manifest-like feature came about when I was working in a high-assurance project a long time ago and it happened once or twice that due to human errors, the two versions didn't match. (not-so-high-assurance..). Tags manifests allows build systems to be able to extract the tagged version information from manifests generated by fossil. This has the positive side-effect that the build system will work in tarballs and zipfiles generated by fossil, as they will contain the manifest files (provided the server has the appropriate manifest settings..). One addition (as per feedback) was to include the current branch at the top of the manifest.tags. It uses the special "branch=" prefix. Note that this is only done when operating in an open working tree. I.e. the branch=... will not be available in generated tarballs and zipfiles, so don't make your build system rely on the "branch="-entry if you want you want the build system to work in exported tarballs or zipfiles. How we use it: Each new released version is tagged using a <projectname>-<version> tag. Our build server checks out a clean copy of a tagged version. The build system iterates through each line of manifest.tags and looks for <projectname>-X.Y.Z (where X, Y, and Z are numbers). Once found, it either uses the version numbers to generate a header file, or a -DVERSION=... argument to the compiler. For non-release builds, such an entry will not be found in manifest.tags, and it will use a special version number to indicate it's a development build. Other uses include using special (propagating) tag names (like "experimental") to make the build system take special actions. We've been using a version of the branch for a pretty long time now, and I'm starting to feel that it's ready for trunkification. For those who are afraid of new features messing with your current setup: The jan-manifest-tags branch is explicitly designed to not interfere with your current setup. You need to take action for a change to occur. If you use "set manifest on" or "set manifest off" it will work exactly like it always has. I.e. if you don't care about this feature, you - as an end user - will not notice it's there (apart an updates settings field and help text). Thoughts? -- Kind Regards, Jan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- CONFIDENTIALITY This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof. ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity. -- CONFIDENTIALITY This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof. ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
