On Aug 15, 2017, at 12:09 PM, Steve Schow <st...@bstage.com> wrote:
>
> I’m hoping to have a version that is stamped into the comments of the actual
> file as well. For example I have some javascripts that are used in another
> entirely closed environment that doesn’t have access to fossil, so it would
> be nice to be able to know which version of the script is being used
You’re doing it wrong.
What you actually want to do here is bake some unique prefix of the Fossil
checkin ID for each .js file into the *distributed file name*. Say the first 8
characters: js/my-script-ABC123CD.js. Then you build a map from
“js/my-script.js” to the generated file name and substitute it in as part of
the build steps.
This allows you to set the web server’s cache expiry time for *.js to something
like “now plus 20 years”, since the file name changes every time the file
*content* changes.
You already need a build system for a web site so you can do linting,
minification, and file merging. All I’m suggesting is that if js/*.js turns
into js/all.min.js now that you modify that process so it generates
js/all.ABC123CD.js where the version tag is based on the latest Fossil checkin
ID for all of js/*.js.
The latest checkin ID for each file is easily extracted from “fossil finfo”
output. There’s only one trick to it: you have to filter out checkin messages
that refer to branches you are not currently on. If someone checks something
in on the development branch but you’re building from a stable branch, you
don’t want the dev branch checkin ID in the file name, you want the newest
checkin ID for that file *on the stable branch*. If you’re on a POSIX
platform, that restriction is easy provided by a single grep call.
I’ve got all of that solved here, but I can’t share it due to it being part of
a closed-source system. But, you probably don’t want my solution exactly,
since it was created before we had all-in-one JS minify/verify/merge tools:
https://stackoverflow.com/questions/9287823/combine-and-minify-multiple-css-js-files
So, pick one of those tools, then rename the resulting CSS or JS file according
to its latest checkin on the working branch in a subsequent build step. Save
that file name mapping somewhere and substitute that file name into the
generated HTML somehow. That latter step is trivial if this site is backed by
something that dynamically generates HTML anyway.
If you aren’t dynamically generating your HTML already, look into the many
static HTML generation tools:
https://www.staticgen.com/
That gets you a build-and-publish model, into which you can substitute the
generated CSS and JS file names.
> what I miss about RCS, is it would bump up the RCS number and could
> substitute that into the source for me during checkout.
There’s a reason keyword expansion was disabled by default in Subversion, and
why the later DVCSes haven’t either not replicated the feature or followed
Subversion’s lead.
If you go Googling, you’ll find lots of “not recommended,” “feature of last
resort,” etc.
Please give up on this misfeature. There are better ways.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
