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
