I'm using NanoBlogger to generate a website that consists entirely of static files—no PHP or anything similar.

I'd like to place the site under version control, which means managing both NanoBlogger's data files and the other non-generated files (stylesheets, images and whatnot) that make up the site with one revision-control system or another. I'd also like to automate deployment of the website from the RCS.

What I've discovered is none of the modern revision-control systems (git, Subversion and Mercurial) preserve timestamps on files they manage. This means a deployment script on the server that checks out a fresh copy of the repository and copies the files over to the webserver's public folder will end up resetting the timestamp on every file, even things like images that haven't changed. This defeats any attempt to use caching effectively and ends up wasting users' time and bandwidth.

So my question is, what tools and workflow do people actually use for versioning and deploying static websites? Specifically, how you get around the timestamping issue? Do you

  • simply keep a "permanent" checkout of the repository on the server which just gets updated before each deployment (arguably a bad practice),

  • use a "classic" RCS like CVS that does preserve timestamps, or

  • ignore the problem and accept a bit of bandwidth will be wasted?

Or is there some completely different kind of system or workflow people use instead?

(There's no shortage of information on the mechanics of using revision control with a website, but I've yet to see anyone address the timestamp issue or say much about static websites specifically.)

  • Why check out the entire version of the repo every time? Once you have the project under vcs just do an update and only get the files that have changed. How does Heroku do it? I guess this only works if you can avoid the copy and put vcs dir where you need it on the server. Commented Jan 28, 2014 at 17:07
  • The motivation for checking out a fresh copy every time is to make sure what's deployed is always exactly what's current in the repository. Largely this is about enforcing the rule that nothing should be deployed that hasn't been first tested and then stored safely in the RCS.
    – user13260
    Commented Jan 31, 2014 at 12:13

1 Answer 1


No VCS includes timestamp as metadata, even some do include permission bits. I think it's because when VCS tracks file contents, the last-modified time is not coherent. E.g. when someone modify a file, then undo, the last-modified time changes, but that file should keep the same version.

BTW, Subversion has an option use-commit-times to use commit time as file timestamp. Thus it could help a bit.

  • That should pretty much solve the problem if he uses SVN. Alternatively, he could use the revision number in the ETags and just disable the last-modified header, which would also solve the problem. Commented Feb 11, 2012 at 6:00
  • Just want to add that, to solve the OP's problem, we'll simply ignore the last-modified. It's not a real problem. Don't care about time or bandwidth, because they are very cheap, and the modification time does not change often, does it?
    – jcisio
    Commented Feb 11, 2012 at 23:59
  • If he doesn't do any rollbacks then he won't need to suppress the last-modified header, and it'll work perfectly (only using bandwidth when a new commit has been made). However, if he does do any rollbacks, then the file will have changed but the browser won't re-fetch it because the last-modified will be set even further back than it was before. This would be problematic. This is where ETags might be a better solution. Commented Feb 12, 2012 at 11:07
  • Thanks, guys. Using Subversion with the use-commit-times flag sounds like the best solution here. (However, I've already started using CVS and will probably stay with it; it's good enough for now, uses timestamps the way I think an RCS should, and has the benefit of not requiring any extra software on the server.) Using ETags would be a clever solution, except they are not supported (well) by nginx which seems generally to be the best option for serving static websites.
    – user13260
    Commented Feb 12, 2012 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.