On Fri, Feb 4, 2011 at 2:40 PM, Mike Meyer <mwm-keyword-fossil.1d1...@mired.org> wrote: > On Fri, 4 Feb 2011 13:44:18 -0800 > Brian Smith <br...@linuxfood.net> wrote: > >> For some personal sites, what I do is I actually have the fossil repo >> opened in the web directory. >> It's .htaccess'd off so that you can't get at it, even if you know it's >> there. > > Any particular reason to keep the repo in the web directory? Wouldn't > putting it somewhere outside whatever security wrapper you have on the > web server make more sense?
The sqlite file that contains the artifacts isn't (usually) in the webroot. It's stored elsewhere, but, the webroot is a checkout of the repository, which is necessary so that fossil up will actually update the files. I suppose I could modify it so that it opens and closes a checkout to make it more "secure", but, I tend to err on the side of trusting my tool (apache in this case), rather than supposing it'll be compromised at any second. ( Especially when you consider how long apache has been around and it's generally favorable security record, I don't think it's unreasonable to trust it's "security wrapper". ) As far as sense goes, I think my setup makes perfect sense. :) > >> Then, I've got a cronjob that once every 15 minutes does a 'fossil >> update release'. >> Where 'release' is just a tag that I apply to checkins that I feel are >> ready. I could probably also have a 'vX.Y.Z' tag so that I could force >> it backwards too, but, they're just personal sites. :) > > I've done this kind of thing with perforce for a couple of clients, > including automatically syncing to test, q/a and then production > servers. > >> I could probably also wrap it in a script that did more complicated >> release logic, if I wanted. > > Based on my experience, you don't really need much release logic in > the script. While mine was wrapped in a script, most of the script was > to parse the output of the update command to find > added/changed/deleted files to have the search engine > index/reindex/delete them. > My solution requires "no" logic at the moment. I cd into a directory and run 'fossil update release'. What I was alluding to about "complicated" logic was something that maybe looked at "version tags", and updated to the latest version tag that also contained the tag "release". Or performed some pre-release actions such as running db schema updates. Just as an example. I won't speak to whether or not it "makes sense" to automatically run database schema updates. > > Just create branches for the various sites in the release process > (test, q/a, production or whatever) have each site open on the > appropriate branch, with the repo autosyncing so the update command > will pull from the master, and then your release process can focus on > updating the branches in the master repo properly, and the web sites > will follow along automatically. > As I said, these are personal sites and thus don't require anything other than a single release tag. The way to make an automatic release is: 'fossil tag add release trunk' 'fossil sync'. And, I'm done. A side-effect, that, I haven't tested, is, I could also cancel the release tag, and I'm relatively sure that the site would roll back. It also means that I could also setup any other arbitrary tags that I wanted, such as 'stable', or 'testing', or 'monkeys' (because who doesn't love monkeys?) and the process would be the same. -B _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
