well…its not for a website…javascript is used for a lot of stuff out there besides the web. Its not practical for the name of the file to have a version encoded into it.
> On Aug 15, 2017, at 2:25 PM, Warren Young <war...@etr-usa.com> wrote: > > 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 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
